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

Gaetan Nadon memsize at videotron.ca
Fri Jan 4 13:22:05 PST 2013

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.

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.

> Cheers,
> Peter

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20130104/7c8e9277/attachment.html>

More information about the xorg-devel mailing list