Tom Lane writes:
Ankur Sinha <sanjay.ankur@xxxxxxxxx> 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.
Attachment:
pgp_DKyUwYvmg.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
