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

[Guo, Yejun]

> -----Original Message-----
> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf Of
> Alexander Strasser
> Sent: Tuesday, May 07, 2019 6:21 AM
> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH V5 1/2] configure: sort
> decoder/encoder/filter/... names in alphabet order
> 
> 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(-)

I have no idea which one is better, but I think this point is not the reason.

we can refine the shell patch as below with 15 insertions(+), 2 deletions(-1). Actually, the line number does not mean something. :)

print_in_columns() {
    # the input should not contain chars such as '*', otherwise it will be expanded.
    set -- $(tr ' ' '\n' | sort)
    test $ncols -lt 24 && col_width=$ncols || col_width=24
    cols=$(($ncols / $col_width))
    rows=$(($(($# + $cols - 1)) / $cols))
    cols_seq=$(seq $cols)
    for row in $(seq $rows); do
        print_index=$row
        print_line=""
        for col in $cols_seq; do
            test $print_index -le $# && eval print_line='"$print_line "${'$print_index'}'
            print_index=$(($print_index + $rows))
        done
        printf "%-${col_width}s" $print_line; printf "\n"
    done | sed 's/ *$//'
}

the usage of "test && ||" is already used in configure.

> 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
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".