[PATCH 0/5] xserver: configuration/packaging janitorial maintenance
gaetan.nadon at videotron.ca
Thu Nov 12 05:27:14 PST 2009
On Wed, 2009-11-11 at 21:39 -0800, Keith Packard wrote:
> Excerpts from Jeremy Huddleston's message of Tue Nov 10 09:20:22 -0800 2009:
> > Thanks for doing this.
> Indeed! I have only one additional comment to those already voiced --
> one of these patches removes autogen.sh from the set of files
> distributed in the tarball. That is required to regenerate the
> autoconf/automake output when changing the configure.am file, and so
> I'm concerned that this will make minor bug fixing harder (as our
> configure scripts are certainly not bug-free). Is there something
> 'bad' about distributing this file?
It appears I am missing the first part of the discussion. This
maintenance item is one where I am continuing what has been started
sometimes in the past. There were about 30 modules out of 252 that were
shipping autogen.sh. Others have been changed over the past year or so.
There are two kinds of builds. One from git where developers build from
scratch and are considered "maintainers" from the GNU Build System view
point. They can change a module configuration in addition to compile the
code. The other kind of build is from tarballs that we distribute. Git
is not available and configuration tools are not required. The INSTALL
file instructs tarball builder to run ./configure and "make install".
The tar builder are not considered "maintainers" and are neither
required nor expected to change the configuration.
There are build rules that are enabled for "maintainers" only. In
configure.ac , AM_MAINTAINER_MODE disables these rules by default. The
consequence is that tarball builders cannot invoke these rules. The
reason is to protect files that cannot be regenerated when we anticipate
that tools to regenerate them would not be available. There was a case
where ChangeLog was exposed to be removed by a normal clean target and
cannot be regenerated as it is generated from git and git is not
available to tarball builders.
The autogen.sh isn't part of the GNU Build System. It is used by
developers to bootstrap the git obtained build and it is used as a
convenient interface to build.sh to pass options that it computes for
various modules. Without it, you only need to invoke "autoreconf -vi"
followed by "./configure --prefix $prefix". Because we want the
maintainer rules available to X.Org developers, we invoke ./configure
with --enable-maintainer-mode. For tarball builders, they only need to
run ./configure and make install. This is documented in an excellent way
in the Automake default INSTALL file that I am working to include in a
I speculate the reasons why autogen.sh isn't shipped is that it isn't
necessary, isn't documented, and it adds confusion by providing an
alternate way of invoking a build. Even worse when some modules have it
and others don't. We need to be able to explain to builders/installers
is a simple way how things work. I noticed in the Debian build log that
they redo the configuration by running autoreconf, most likely because
they have patches to apply.
All the discussion above is about default behaviour. Anyone, like
Debian, can completely reconfigure a module by issuing autoreconf in a
totally legitimate way. In my opinion, autogen.sh is great for our git
development but should not be distributed, even if we discard the
"maintainers build rules" feature.
What also motivates me to complete this work, is that currently the
modules are in inconsistent state. Some ship autogen, some don't. Some
have AM_MAINTAINER_MODE and some don't. Some are starting to remove
--enable-maintainer-mode. If all 252 modules implement the same
behaviours the same way, and if it is documented (and it is now in
http://wiki.x.org/wiki/NewModuleGuidelines) there is less chances that
we will produce tarballs that don't build the same way.
If we desire different behaviours, then they should be documented and
implemented in all modules.
--enable-maintainer-mode enable make rules and dependencies not useful
(and sometimes confusing) to the casual installer
> xorg-devel mailing list
> xorg-devel at lists.x.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xorg-devel