On Thu, 11 Mar 2021 at 12:04, Kevin Kofler via devel <devel@lists.fedoraproject.org> wrote:
[..]
I really do not understand why so many upstreams are still using autotools.

Because ItWorks(tm)

A build system that fails so badly at backwards compatibility (This is not
the first time autoconf has changed incompatibly!) is just a pain for
everybody.

"Even in perfect language it is possible to write bad/buggy code".
Here is my latest example (only few days old) that proves that this theorem/statement still holds against all odds ;)
https://github.com/ofiwg/libfabric/issues/6614

Issue is that sometimes people really don't want (first) to understand how to use the exact tool (it starts from something like "I'm not going to read anything because I want to just use it!!") or look at some already working examples (those cases are even worse :)).
Those people prefer to discover how to use it without reading even a single line of necessary documentation.
I know that .. because I'm one of those and here probably you can find much more such people :P

That behaviour happens all the time and is older than our technical civilisation :)
Better .. thanks to those "brave" people, some of them are able to invent something completely new (because of the "traumatic" experience of using something without learning it).
Funny (and scarry) thing is that sometimes those new tools are better than old one :o)
(most of the time are even worse like scon or waf)
In other words it is hard to blame for that anyone here because from exact angle even something so bad objectively is not 100% bad because time to time that pushes forward The Progress :P

There are alternatives (such as CMake) that handle backwards
compatibility in a much more graceful way. (In fact, the most incompatible
CMake-related change so far was actually a change in the %cmake RPM macros
and not in upstream CMake.) But autoconf still releases breaking updates.

IMO cmake is one tf he worst recent build tooling because it does not introduce good standards of some well known operations and only that opens widely all gates for sometimes freakishly implementations of doing NormalThings(tm).
Working on sometimes a few hundreds packages each month most of the problems on which I'm able accidentally  stump are related to cmake than probably equally to ac/am/lt and meson. And yes .. some people already started inventing OwnWays(tm) using meson 8-)

And not only the new autoconf breaks updates of other packages.
That is an immanent feature of all new versions of all software which interact with other software :P

Nevertheless above part is completely off-topic from the subject introduction of the ac 2.71 in Fedora.

I can only repeat that instead of conserving current state and swiping some issues under the carpet by introduction of compat-autoconf-2.69 to deal with only a handful of packages with some ac 2.71 issues it would be better to form a list of those packages.
Because the new f35 cycle just started now is the best moment to expose and sort out all those issues.

Again: IMO in a few days it is possible to properly identify all those problematic packages by performing test builds with redefined over command line single macro on all packages with "%configure" used in the spec file.
In this case we are talking about testing ~3.7k packages of all ~21.7k Fedora packages.
After fixing all those issues it will be possible to close the coffin with autoconf-2.69 and at least in f35 will have one package less ..

And at the end I would like only gently recall that still it is yet another (sub)subject of even older autoconf still used by firefox & co :P
Who wants to grind that? :P

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH