Hi,
Ryan Carsten Schmidt wrote:
One additional benefit to always using autoreconf is that we avoid the
possibility that a pre-made configure script contains malware. This is an
unlikely scenario, requiring the compromise of a project developer, but it did
occur in xz-utils:https://tukaani.org/xz-backdoor/
One reason why we have typically avoided using autoreconf where possible is to
save time. But on today’s computers the added time to run autoreconf is much
less than it used to be.
Ancient projects may have build systems that cannot be processed correctly by
modern autoconf. I’m fine with taking those on a case by case basis either
trying to fix the build system so modern autoreconf can run, or using an older
autoconf (we have ports for several versions), or using the old generated
configure script.
If we do this, we must be careful not to introduce dependency cycles. Anything
that is a recursive dependency of autoconf, automake, or libtool can’t be
autoreconf’d. Bear in mind older systems sometimes have more dependencies (e.g.
newer compilers).
my humble opinion is "no, let's not do it standard". There may be one or
the other ports that needs it, but generally speaking, no
As a long-time developer involved in projects, autoreconf often asks for
trouble, regenerating some thing not working.
First example? changing version. Upgrade is not so easy often, it may or
may not work. and it may break in subtle way. 2.13 is a notorious thing,
but even 2.5x and 2.6x have differences, especially if the project came
which its own scripts.
Even using the same version may cause issues if run with a different
environment (shell, operating system... whatever. Most often the
original was generated on Linux with bash).
Second example? Nested projects, where there are more configure and/ore
makefiles.
and the list goes on I don't remember off-head, but the topic is
"delicate" to say the least. Then, maybe it works, but I broke things by
just having an environment set or a different shell.
So applying it flat to everything could be ticking bomb.
Riccardo
