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

[Gaetan Nadon]

On 13-01-06 08:41 PM, Peter Hutterer wrote:
> 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)
I see now. I was under the impression that all distros were always doing
autoreconf.
Sure, it would not hurt to have AM_MAINTAINER_MODE([enable]).
>
> 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
>>>
>>