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 > > > > > >> > > > > _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
