[FFmpeg-devel] [PATCH V5 1/2] configure: sort decoder/encoder/filter/... names in alphabet order

[Alexander Strasser]

On 2019-05-05 21:14 +0000, avih wrote:
> > I guess you were looking at the right patch. I mean this one:
> >   http://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/243380.html
>
> I was referring to this patch indeed. Thanks.
>
>
> > > > Agreed; of course we shouldn't just use awk because we can.
> > > >
> > > > Though I think not implementing things in shell is often
> > > > lower risk, as we have no isolation in POSIX shell, we all
> > > > share the same variables etc. and the configure script is
> > > > quite big. Then shell is not suited for many tasks because
> > > > of the way it works
> > > > ...
> > >
> > > This actually sounds to me like you're saying we shouldn't use awk because
> > > we can, but rather use it where possible because it'd be better than shell.
> > >
> > > In other words: we should write new configure code in awk.
> > >
> > > Did I misinterpret the statement or its implications?
> >
> > You got me totally wrong :(
>
>
> I'm only human, it happens. But you didn't explain what you actually meant.

It's a communication problem. I tried to explain why I prefer
the awk version over the shell version of this patch in the email
before. Seems I was too vague.

I will try to answer your specific questions. If there is more
to discuss, please don't hesitate to ask.

> Specifically:
>
> - What makes this patch a good candidate to use awk rather than shell like
>   the rest of configure?

I would like to rephrase this question a bit. I guess the other aspect
will be in my answer to your next question anyway.

patch1 (awk) configure: print_in_columns: replace pr with awk version: http://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/243380.html
patch2 (shell) configure: sort decoder/encoder/filter/... names in alphabet order (v5 as posted in this thread)

- Why do you prefer patch1 over patch2?

1. Statistics
    * patch1: 1 file changed, 16 insertions(+), 2 deletions(-)
    * patch2: 1 file changed, 24 insertions(+), 2 deletions(-)
2. patch2 uses lots of variables (which is good in itself), but those
   should be local and we cannot express that portably in shell.
   In turn we have raised potential for clashes now or in the future.
3. patch2 uses eval combined with non-trivial quoting, which is hard
   to read and hard to grasp quickly. It's not wrong, but it's not as
   easy and straight forward as in patch1.
4. Depending on the input (stdin) unexpected things can happen in the
   "eval" and "set" lines. One example is given in the comment.
5. patch2 to uses shell for the parts easily expressed in shell and
   uses awk for the parts that are non-trivial in shell.
6. The awk implementation should be easier to read and understand for
   the majority of readers/developers.


> - What should be the general criteria to choose a scripting language for
>   future patches?

I don't see anywhere that we switch away from shell for configure. So in
general things should be implemented in shell. Shell though is not really
suited for implementing all kinds of algorithms. OTOH shell is an excellent
choice for starting processes that communicate via stdin/stdout/stderr
and plugging them together.

So I think programming shell, sticking only to shell itself (builtins) is
almost never a good option. Shell is best when coordinating the execution
of other programs. Sometimes when you do not have a particular program
around to help you in your shell script, that void needs to be filled.
For this purpose awk is often a good choice, because it was especially
designed to be a fit for this purpose amongst other things. Using only awk
to implement bigger systems or as a general purpose programming language
is IMHO nearly as wrong as using shell-only.


>     On Saturday, May 4, 2019 10:43 PM, Alexander Strasser <eclipse7 at gmx.net> wrote:
[...]


I'm feeling like I might not have expressed my reasoning good and
precise enough in every level of detail. I apologize for that. My
natural language skills have their limits and I am not a native
English speaker. I will try to refine specific points, should you
or anyone else have more questions or comments.


  Alexander