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