Patch ./configure, or use instead?

Joshua Root jmr at
Tue Feb 15 09:08:50 UTC 2022

On 2022-2-15 19:28 , Jim DeLaHunt wrote:
> I am working on a port[1], where I want to patch a couple of autoconf 
> macros[2] and . The unpatched macros give 
> -Wimplicit-function-declaration errors, but they are easy to fix via 
> patches.  However, I discovered that the ./configure script incorporates 
> the unpatched behaviour of the macros, so `port configure` still causes 
> the -Wimplicit-function-declaration errors.
> The codebase supplies a script, ./ . It runs autoconf, 
> libtool, etc. etc. and regenerates the ./configure script, incorporating 
> the fixes from the patched macros. It accepts the same options as 
> ./configure, and passes them on when it calls ./configure .
> I see two ways to solve this:
> a) tell the Portfile to use ./ as the configure command. Let 
> every user rebuild the ./configure script
> b) patch the ./configure script with the same fixes as the autoconf macros.
> Doing a) means the port will have build dependencies on autoconf, 
> automake, etc. etc., and will take longer to run. But will it fail?
> Doing b) means I have to patch something which I think perhaps I should 
> not be patching. I don't see guidance about this, but it feels like a 
> bad approach.

Both approaches can work fine. It's a choice between extra dependencies 
and the possibility that old input files might not be compatible with 
current autotools versions, and maintaining a patch that might get quite 
large and needs to be updated whenever the upstream file changes.

We have a shortcut for option a) by the way: 'use_autoreconf yes'. That 
adds the needed deps for you and usually works fine on its own (plus 
'autoreconf.args -fi' if you want to regenerate absolutely everything 
from scratch), but if special options are needed, you can also set 
'autoreconf.cmd ./'.

I would tend to just patch configure if the change is relatively small, 
and switch to patching and running autoreconf if it gets 
too unwieldy.

When sending changes upstream, you will of course want to do them in, and let upstream handle updating the generated files in 
whatever way they prefer.

- Josh

More information about the macports-dev mailing list