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

[Peter Hutterer]

On Sun, Jan 06, 2013 at 08:27:34PM -0500, Gaetan Nadon wrote:
> 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.

As linked above there really is a use-case for disabling maintainer
mode. And that cannot be done if the macro is removed altogether. so if we
really edit all modules for that, then I strongly recommend leaving it in
with [enabled] so we don't have to edit again to bring it back (which is
what I had to do for wacom, but that's only one module)

Cheers,
   Peter

> >
> > 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
> >
> >
> >>
> >
> 
>