Should we encourage or require ports to use autoreconf?

Riccardo Mottola riccardo.mottola at libero.it
Tue Mar 25 08:11:09 UTC 2025


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


More information about the macports-dev mailing list