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

[Gaetan Nadon]

On 13-01-06 06:02 PM, Peter Hutterer wrote:
> On Fri, Jan 04, 2013 at 04:22:05PM -0500, Gaetan Nadon wrote:
>>
> 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_DEFUN([XORG_DEFAULT_AUTOMAKE],[
> >>> AC_PREREQ([2.60])
> >>> AC_CONFIG_SRCDIR([Makefile.am])
> >>> AC_CONFIG_HEADERS([config.h])
> >>> AC_CONFIG_AUXDIR(.)
> >>>
> >>> AM_INIT_AUTOMAKE([foreign dist-bzip2])
> >>> AM_MAINTAINER_MODE
> >>> ])
> >>>
> >>> 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.
>
> >
> http://old.nabble.com/Re%3A--PATCH-libwacom--Drop-AM_MAINTAINER_MODE-p34696663.html
>
> > I suspect that rather than removing AM_MAINTAINER_MODE across
> modules, using
> > AM_MAINTAINER_MODE([enable]) is the better option.
If you remove AM_MAINTAINER_MODE you should also remove
"--enable-maintainer-mode" from autogen.sh to avoid getting a warning
from "./configure". It is an option to the AM_MAINTAINER_MODE macro.

Having AM_MAINTAINER_MODE([enable]) might have been proposed as a
workaround to the warning. Note that the default for AM_MAINTAINER_MODE
is "disable". Removing the AM_MAINTAINER_MODE statement altogether (with
the matching change in autogen.sh) acheives the same results with the
added benefit that you won't have to explain why the noop
"AM_MAINTAINER_MODE([enable])" statement is there.
>
> 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.
>
> > Cheers,
> >    Peter
>
>
>>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20130106/64be0657/attachment.html>