<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0"> </HEAD> <BODY> On Wed, 2009-11-11 at 21:39 -0800, Keith Packard wrote: <BLOCKQUOTE TYPE=CITE> <PRE> 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? </PRE> </BLOCKQUOTE> 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 ll modules. 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 <A HREF="http://wiki.x.org/wiki/NewModuleGuidelines)">http://wiki.x.org/wiki/NewModuleGuidelines)</A> 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. reference: <TT>--enable-maintainer-mode  enable make rules and dependencies not useful</TT> <TT>  (and sometimes confusing) to the casual installer</TT> Regards, Gaetan <BLOCKQUOTE TYPE=CITE> <PRE> _______________________________________________ xorg-devel mailing list <A HREF="mailto:xorg-devel@lists.x.org">xorg-devel@lists.x.org</A> <A HREF="http://lists.x.org/mailman/listinfo/xorg-devel">http://lists.x.org/mailman/listinfo/xorg-devel</A> </PRE> </BLOCKQUOTE> </BODY> </HTML>