Patch ./configure, or use autogen.sh instead?

Jim DeLaHunt list+macports-dev at jdlh.com
Mon Feb 21 22:32:26 UTC 2022


On 2022-02-21 07:59, Ryan Schmidt wrote:
...[earlier thread elided]...
> 
> It is very common for projects to offer an autogen.sh script....[very helpful commentary elided]...

Thank you for taking the time to write this out, Ryan. It is now on the 
mail archive. I might collect it into a wiki page to make the 
information easier to find for the next person.

> I agree with the previous commentary that recommends patching the configure script and not regenerating it from a patched configure.ac, 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.

I have been working on this port for the last few days, and I was just 
about to post a followup report.

I decided to patch the configure script. I like the idea of the end user 
not having to run autogen.sh and not being dependent on the autotools.

But I also thought, why not also patch the m4 macros which generate the 
configure script? It keeps the codebase on the user's machine 
consistent. It keeps the patches in the MacPorts repository. What harm 
could it do?

I'm glad you asked that!  It turns out that this codebase's Makefile 
includes rules to rerun aclocal, autoconf, and automake if any of the m4
macro files are newer than aclocal.m4, or configure, or config.status,
or a few other files.  When the Portfile patches these m4 scripts, it
updates their modification times to the present, which is newer than 
aclocal.m4.  Thus at build time, the Makefile attempts to perform the
configuration phase all over again. port -t (trace mode) exposes that
this adds dependencies on those autotools.

I worked around this by adding a post-patch clause which used the
"touch -r" macro to reset the modification times of the files I patched 
to be the same an an unpatched macro file. This keeps the Makefile happy.

It might turn out to be smarter to remove the patches and the touches of 
those macro files. It makes for a simpler Portfile. I have not decided.

I am not done with this port yet, but I am making progress, and I am 
learning a ton about MacPorts and autotools. Thank you, everyone, for 
your help with both.

Best regards,
     --Jim DeLaHunt



More information about the macports-dev mailing list