Unified automake init (was Re: xorg-server 1.13.1, - checksum post-mortem)

Peter Hutterer peter.hutterer at who-t.net
Sun Jan 6 15:02:59 PST 2013

On Fri, Jan 04, 2013 at 04:22:05PM -0500, Gaetan Nadon wrote:
> Hash: SHA1
> On 13-01-03 10:18 PM, Peter Hutterer wrote:
> > On Thu, Jan 03, 2013 at 03:55:49PM -0800, Alan Coopersmith wrote:
> >> On 01/ 3/13 03:38 PM, Peter Hutterer wrote:
> >>> is there any particular reason we're still generating gz and bzip2?
> >>
> >> Because we're not hip enough to have replaced gz with xz like all the
> cool kids?
> >>
> >> Or because updating the automake flags in 200+ configure.ac scripts
> is not fun.
> >
> > just played around with this a bit, looks like a the common code for
> > initialising the projects can be moved into a macro, as long as AC_INIT is
> > still in configure.ac. which is the project-specific part anyway.
> >
> > So a common template could be
> >
> > AC_PREREQ([2.60])
> > AC_CONFIG_SRCDIR([Makefile.am])
> > AC_CONFIG_HEADERS([config.h])
> >
> > AM_INIT_AUTOMAKE([foreign dist-bzip2])
> > ])
> >
> > which would make adding options easier in the future. switching to xz,
> > changing/removing AM_MAINTAINER_MODE, etc.
> >
> > note, I've only tested this on a simple test project, not across all xorg
> > modules.
> I had thought about this a while ago, which explains why these lines are
> identical to nearly all modules. I realized I was getting close to the
> point of diminishing return, it was more effort to factor out common
> lines than it was to have them spelled out in configure.ac. It is
> difficult to handle exceptions. In the xserver case, you would have to
> not use the macro XORG_DEFAULT_AUTOMAKE because it does not use
> AC_CONFIG_HEADERS([config.h]). Same for libX11.
> There may be cases where some statements must be found before
> AM_INIT_AUTOMAKE, perhaps AC_CONFIG_MACRO_DIR. Though not terribly
> important AC_PREREQ should be before AC_INIT.
> Invoking any XORG_ * macro from xorg-utils should come after we have
> verified that the it is available with m4_ifndef. This verification can
> be move at the top of the file now that it not longer uses AC_FATAL
> macro it used to.
> The macro mixes AC_ and AM_ statements which leads to those
> contradictions. More robust re-usability could be obtained by limiting
> its content to  AM_INIT_AUTOMAKE([foreign dist-bzip2]). The macro name
> would then fit perfectly.
> I can't see any other lines that could be factored out without causing
> problems in some modules. The sad part is that you cannot make
> assumptions and need to test them them all as you don't know which
> modules will be the exceptions.
> AM_MAINTAINER_MODE should be removed anyway as it was done in xserver. 
> AC_CONFIG_AUXDIR(.) is not needed.

I really just copied this from (I think) evdev or so and played around with
a few things. so it's certainly not yet the best solution.

as for AM_MAINTAINER_MODE, when I removed it from the wacom driver I
actually got a request for AM_MAINTAINER_MODE([enable]) instead. Ron, the
debian wacom maintainer, actually commits _all_ generated files as well to a
branch. this way he has a known-working tree available, but he needs to
disable maintainer mode to avoid re-generation of the files on checkout.


I suspect that rather than removing AM_MAINTAINER_MODE across modules, using
AM_MAINTAINER_MODE([enable]) is the better option.

> The type of file archiving is likely to get changed in the future so
> it's worth doing. Particularly that when it needs to be done, it needs
> to be done on all packages. Getting people to agree on the content is a
> different matter.
> ||

right. given that we still need gz at this point I reckon it's not worth the
hassle for now.


> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
> SZgAoIx2TIY/2cPRwDEwOxnCSlfqUlf+
> =AulD

More information about the xorg-devel mailing list