Patch ./configure, or use instead?

Ryan Schmidt ryandesign at
Mon Feb 21 15:59:04 UTC 2022

On Feb 17, 2022, at 14:10, Jim DeLaHunt wrote:
> On 2022-02-16 23:12, Jason Liu wrote:
>> is quite often just a wrapper around autoreconf -i. If you run 'autoreconf --install' (which is what 'use_autoreconf yes' runs), in many/most cases it's equivalent to running
>> <>
> Thank you for the link, Jason.
> The contents of this project's ``[1] are not simply a call to `autoreconf -i`. There are 346 lines, 3 functions, and a sequence of calls to autotools components like aclocal, autoheader, libtoolize, autoconf, and automake. Interestingly, it calls aclocal twice: once
> before autoheader and libtoolize, and again after.
> This `` was first checked in back in 2002, with quite a similar structure to what it has today. I am guessing that it predates
> `autoreconf`, and that the project has never decided to do the work of
> switching over to `autoreconf`.
> I think I don't want to take on that switchover as part of improving
> the MacPorts port of this codebase.
> Thank you for the tips, everyone. I am learning a lot, even if I'm
> not checking in code as a result.
> [1] <>

It is very common for projects to offer an script. If they do, it is preferable to use it, rather than just run autoreconf. Even if just running autoreconf works today, you don't know in what ways the project's authors will change their script over time. I do find that the need for separate scripts is diminishing and I do see projects dropping their custom scripts in favor of just using autoreconf, but you're right to leave that decision to the project's developers.

While "" is still the most popular name for such a script, it is recommended for the script to be named "bootstrap" instead, so you may find projects that use that script name.

Some and bootstrap scripts end by running the configure script with the args that were supplied to it. In this case, if you wish, you can set "configure.cmd ./" and add autoconf, automake, libtool, and any other needed dependencies to depends_build manually.

Some and bootstrap scripts either never run the configure script or they honor an environment variable that you can set to tell it not to do so. In this case, you could use "use_autoreconf yes" and "autoreconf.cmd ./" and "autoreconf.args" (to clear it) and possibly "autoreconf.env NOCONFIGURE=1" or similar (read the script to find out). MacPorts will then run for you as its own isolated command before running the configure script as it normally would. Overriding autoreconf.cmd deletes the autoconf, automake, and libtool dependencies that "use_autoreconf yes" adds, so you have to add them again manually. Do so after overriding autoreconf.cmd, not before.

I agree with the previous commentary that recommends patching the configure script and not regenerating it from a patched, if that's simpler. Make sure that you decide which method you want to use, and only patch either the generated files or the files they're generated from, as appropriate to your decision.

More information about the macports-dev mailing list