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

[Ryan Schmidt]

On Feb 21, 2022, at 16:32, Jim DeLaHunt wrote:

> 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.

It's not just this codebase that does that; it's a feature of autotools. That's 
one of the reasons why I said to decide whether to patch the generated files or 
the files they're generated from, not both.

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

[Jim DeLaHunt]

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

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

[Ryan Schmidt]

On Feb 17, 2022, at 14:10, Jim DeLaHunt wrote:
> 
> On 2022-02-16 23:12, Jason Liu wrote:
>> autogen.sh 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 autogen.sh.
>> 
> 
> Thank you for the link, Jason.
> 
> The contents of this project's `autogen.sh`[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 `autogen.sh` 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 autogen.sh 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 "autogen.sh" 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 autogen.sh 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 ./autogen.sh" and add autoconf, automake, libtool, and any other 
needed dependencies to depends_build manually.

Some autogen.sh 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 ./autogen.sh" 
and "autoreconf.args" (to clear it) and possibly "autoreconf.env NOCONFIGURE=1" 
or similar (read the script to find out). MacPorts will then run autogen.sh 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 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.

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

[Jim DeLaHunt]

On 2022-02-16 23:12, Jason Liu wrote:
autogen.sh 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 autogen.sh.





Thank you for the link, Jason.

The contents of this project's `autogen.sh`[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 `autogen.sh` 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] 

Best regards,
 --Jim DeLaHunt

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

[Jason Liu]

autogen.sh 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 autogen.sh.

https://stackoverflow.com/questions/50044091/what-is-the-job-of-autogen-sh-when-building-a-c-package-on-linux

-- 
Jason Liu


On Wed, Feb 16, 2022 at 11:15 PM Jim DeLaHunt 
wrote:

> On 2022-02-15 01:08, Joshua Root wrote:
> >
> > 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 configure.ac 
> >> The codebase supplies a script, ./autogen.sh . It runs autoconf,
> >> libtool, etc. etc. and regenerates the ./configure script,
> >> incorporating the fixes from the patched macros
> >>
> >> I see two ways to solve this:
> >> a) tell the Portfile to use ./autogen.sh as the configure command. Let
> >> every user rebuild the ./configure script
> >> b) patch the ./configure script with the same fixes as the autoconf
> >> macros
> >
> > ...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 ./autogen.sh'
>
> Thank you for the reply, Joshua.
>
> You mention autoreconf. I just learned something new! I did not know
> about autoreconf[1], a tool included in autoconf.
>
> It looks like upstream does not use autoreconf. They have a shell script
> `autogen.sh`. For all I know it is something they created themselves.
> Like autoreconf, it runs autoconf, automake, libtoolize, etc. etc. I
> have no assurance that I can replace it with autoreconf.
>
> Thus I think I will try running ./autogen.sh in place of ./configure,
> and see how far that gets me. It is good to know that patching
> ./configure is not out of the question.
>
> Best regards,
>  --Jim DeLaHunt
>
> [1]
> <
> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/autoreconf-Invocation.html
> >
>

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

[Jim DeLaHunt]

On 2022-02-15 01:08, Joshua Root wrote:


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 configure.ac 
The codebase supplies a script, ./autogen.sh . It runs autoconf, 
libtool, etc. etc. and regenerates the ./configure script, 
incorporating the fixes from the patched macros


I see two ways to solve this:
a) tell the Portfile to use ./autogen.sh as the configure command. Let 
every user rebuild the ./configure script
b) patch the ./configure script with the same fixes as the autoconf 
macros


...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 ./autogen.sh'


Thank you for the reply, Joshua.

You mention autoreconf. I just learned something new! I did not know
about autoreconf[1], a tool included in autoconf.

It looks like upstream does not use autoreconf. They have a shell script
`autogen.sh`. For all I know it is something they created themselves.
Like autoreconf, it runs autoconf, automake, libtoolize, etc. etc. I
have no assurance that I can replace it with autoreconf.

Thus I think I will try running ./autogen.sh in place of ./configure,
and see how far that gets me. It is good to know that patching
./configure is not out of the question.

Best regards,
--Jim DeLaHunt

[1] 

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

[Joshua Root]

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 configure.ac . 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, ./autogen.sh . 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 ./autogen.sh 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 ./autogen.sh'.


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


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


- Josh

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

[Jim DeLaHunt]

Hi, folks:
[resend, sent to old domain name at first, sorry]

I am working on a port[1], where I want to patch a couple of autoconf 
macros[2] and configure.ac . 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, ./autogen.sh . 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 ./autogen.sh 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.


I think that telling the Portfile to use ./autogen.sh is simply a matter 
of these directives:


configure.cmd        ./autogen.sh

depends_build   port:pkgconfig \
    port:autoconf \
    port:automake \
        port:libtool \
        port:m4

Comments? Advice?
    --Jim DeLaHunt

[1] Major rewrite of freeciv port, https://trac.macports.org/ticket/62984
[2] https://trac.macports.org/ticket/64551#comment:3

--
.--Jim DeLaHunt, Vancouver, Canada