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

avih avihpit at yahoo.com
Sat May 4 09:28:52 EEST 2019


> On 2019-05-02 08:55 +0000, avih wrote:
> > > It seems awk is unconditionally required already. However I wanted to
> > > say that it's a very nice dep to have
> >
> > While it's possibly nicer than other deps to have, it's still better to use
> > it IMHO only when it adds some value, like simpler code, better performance,
> > compliance with some things, etc.
> 
> 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?

Assuming I interpreted it correctly, my opinion on this is that configure
is already written in shell, so unless there's a consensus to migrate it
to awk, things should stay shell except where other tools add some value
beyond "this doesn't have the general issues of shell". I.e. use tools
where they are better suited for some specific tasks than shell.

Personally I don't have an opinion about migrating configure, though I'd
think that if such migration ever happens, it should be to a proper build
system and not just a different scripting language.


> Also in my experience the shells differ, when using more
> advanced concepts and in things that aren't used widely.

True, though I don't think configure uses exotic shell features, and
as far as I know it's currently posix and real-world compliant with
many new and old shells. If you know of a valid issue with some shells,
you can report it or send a patch.

Note that I'm not arguing that shell is a great programming language.
It's not - it's hard and it's treacherous. But currently that's what we
have, and for now it does its job.


> > With this patchset, for part 1 I'm not sure I see the added value with awk,
> > as it looks about the same complexity of the code compared to the shell
> > version.
> 
> Did you look at the version I attached in this thread? Or the one I
> posted in the new patch set?
> 
> I changed it to use an algorithm more similar to the latest shell
> version discussed here.

I think so, yes. As I said, it's similar to the shell version. I don't
think it's worse in any way, but I also didn't see an added value.

Please post a link to the actual patch if you think I'm not looking
at the patch version you refer to.



More information about the ffmpeg-devel mailing list