Calling autoconf in a spec.

[Sam Varshavchik]

Tom Lane writes:

> Ankur Sinha <sanjay.ankur at gmail.com> writes:
> > I need help with a package[0] that needs autoconf to be called before
> > the build can begin. I've read this draft which addresses the issue[1].
> > I used the second solution which says:
>
> > "When manual modification of configure or Makefile.in for the purpose of
> > generating a patch is impractical, packagers can create a patch by
> > regenerating configure and/or Makefile.in to use as input to diff. In
> > general, autoreconf should not be used for this purpose because it will
> > regenerate files that probably don't need to be regenerated. "
>
> > This fixed the build on my F15, but didn't work on F14. How should I go
> > about handling this please? Should I just call autoconf in the spec and
> > be done with it?
>
> Sure.  As pointed out on the wiki page, that policy is controversial;
> you should not feel bound by it.  At the same time you should realize
> why it's there: the concern is that when autoconf changes versions,
> that could unexpectedly break your package.  Personally I don't think
> that's significantly more likely than changes in any other build tool
> breaking your package, but YMMV.
>
> FWIW, I used to run autoconf during the builds of both the postgresql
> and mysql packages for many years.  That eventually became unnecessary
> in both cases, but I don't recall that autoconf changes ever caused me
> any trouble.  (gcc, on the other hand, ...)

To add to that: I never recall a single instance where I couldn't fix any  
breakage in someone else's canned configure/makefile scripts without having  
to rerun autoconf and automake.

If there was a problem in the configure script, rather than patching  
configure.ac or configure.in, I simply patched the configure script itself.  
Once you understand how autoconf spews out the configure script, and you've  
looked at a sufficient number of various configure scripts, figuring out how  
to patch it directly, so it does what you want, is not rocket science.

If there was a problem in the makefile, I always found a way to patch the  
Makefile /after/ running configure. With a reproducible build, you should  
always get the same Makefile after running configure, and that can be  
patched at that point. Patching Makefile.in might result in the final  
Makefile attempting to rebuild itself via automake, producing a big mess,  
but it's always safe to patch the final Makefile.

Even with libtool thrown in the mix, I was always able to find a way to  
patch the final scripts themselves, rather then the templates they get  
generated from. Finally, all they do is control the resulting build, and  
sometimes whatever needs to be fixed, can be fixed by patching the actual  
source, itself. If configure is not setting some preprocessor macro  
correctly, just patch the define directly into the right header file,  
instead of patching configure to do it, and move on with your life.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110703/49fdfb8c/attachment.bin