Re: Managing changes to configure.in as patches
On Thu, Jan 08, 2004 at 06:13:30PM -0500, Joey Hess wrote:
> Matt Zimmerman wrote:
> > > 2. does not hide problems if it does no longer build with current
> > > autotools
> >
> > The other approach does not hide problems either; it prevents the problem
> > entirely. It becomes no longer an issue what version of the autotools are
> > installed in the build environment.
>
> The fact that a package's maintainer has needed to modify its
> configure.ac is a good indication that a user might also have reason to
> modify it later. If the autotools then fail to work to generate the
> configure for that user, then a hidden problem has indeed surfaced, I'd
> say.
If autoconf is run ahead of time, things only break if _all_ of the
following are true:
1. The user is performing a custom build
2. The user needs to modify configure.ac, Makefile.am, etc.
3. autotools have broken themselves since the last time the maintainer ran
autoconf, automake, etc.
On the other hand, if autoconf is run as part of the build process, then
things break if the autotools have broken themselves since the last time the
package was autobuilt, regardless of any other conditions.
I think that the former is preferable.
--
- mdz
Reply to: