[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Autoreconfing guide



Yavor Doganov <yavor@gnu.org> writes:

> Probably you're right; I guess this is due to the misarable experience I
> had in the past, with Gtk+/GNOME packages in particular.  Even now if I
> look at the packages I maintain, they're full of underquoted and
> obsolete macros.  These things are fixable, as you say, but some
> upstream maintainers are very reluctant to incorporate changes to the
> build system.  I have seen my proper m4 quotation deliberately removed
> and classified as "obfuscation".  In this age, some people still use
> AC_TRY_* macros in new packages because that is what they copy/pasted
> eons ago.

Yes, you're not wrong.  I suppose the caveat I should attach to my
experience is that I'm a fairly experienced Autoconf user (dating back to
the version 1 days, in fact, although I only started using it in earnest
with version 2), so while writing detailed m4 macros is usually beyond me,
I can fairly easily debug and fix most Autoconf scripts.  People with less
experience will be less comfortable being aggressive about this.

I do wish that more maintainers would treat Autoconf with the same care
that they would treat, say, their C or Perl or Python coding style and
stay similarly current in the language.  It's not that hard to go through
the changelog of new Autoconf releases and adjust for new recommended
macros.  But if you don't do it regularly, the accumulated work becomes
intimidating.

> What about packages that use a custom bootstrap script and/or gnulib?
> Should gnulib be updated too?

I would not update gnulib.

A good case can be made to do this, but, as you say, it's dangerous.  The
huge difference with gnulib vs. Autoconf and Automake is that the latter
don't contain any code that actually makes it into the final binaries.
You can get some weird bugs, but by and large the software just doesn't
build, or, worst case, builds with the wrong libraries.  Updating gnulib
can violate the expectations of the actual code, and possibly even
introduce security vulnerabilities.  That's a lot trickier.

Most of gnulib *should* be inactive on a current glibc system, although I
know that's not always the case.

> What about packages which have AC_PREREQ for an Autoconf version that is
> not yet packaged for Debian, or depend on a new Automake version/feature
> (a minor issue, but it has happened in the past)?

This used to be quite common, but honestly I've not seen it in years.  A
lot of the concerns that people have about always running autoreconf were
completely valid and correct five years ago or so, but they've gotten a
lot more stable (in part because upstream development of the projects has
died down a bit again).

> I also wonder why debian/autoreconf is needed given that autoreconf
> is recursive.

I don't think autoreconf can always figure out what to do when the files
are buried in some random subdirectory without anything at the top level.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: