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

Re: Autoreconfing guide



Russ Allbery wrote:
> Yavor Doganov <yavor@gnu.org> writes:
> > However, this is not how the GNU build system is intended to be used.
> 
> Meh.  I think this is a non-issue.

I didn't mean it is an issue in that sense.  Such usage will reveal
unexpected bugs, that's all.  It may be even welcomed by some of the
upstream GNU autotools maintainers as that will reveal bugs in their
code, too.

Some of these bugs may be hard to spot (for example, miscompilation or
misbehaviour of a particular test as opposed to FTBFS) and may sneak
into stable releases.

I won't comment on the points you raise because they are valid if you
consider Autoconf a shell compiler (which it is, in a sense) and
Automake a makefile generator.

> I find your concerns excessively alarmist.

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.

> I have been rebuilding all the Autoconf and Automake files from
> scratch for all packages I maintain for quite some time now,
> including some very complex packages and packages with a mess of
> Autoconf macros, and have had few problems

For a well maintained build system that follows the recommended
practices autoreconf-ing is unlikely to cause trouble.

What about packages that use a custom bootstrap script and/or gnulib?
Should gnulib be updated too?  This is potentially dangerous.  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)?

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


Reply to: