<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> On 13-01-06 06:02 PM, Peter Hutterer wrote: > On Fri, Jan 04, 2013 at 04:22:05PM -0500, Gaetan Nadon wrote: >> <blockquote type="cite">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. > <a class="moz-txt-link-freetext" href="http://old.nabble.com/Re%3A--PATCH-libwacom--Drop-AM_MAINTAINER_MODE-p34696663.html">http://old.nabble.com/Re%3A--PATCH-libwacom--Drop-AM_MAINTAINER_MODE-p34696663.html</a> > I suspect that rather than removing AM_MAINTAINER_MODE across modules, using > AM_MAINTAINER_MODE([enable]) is the better option. </blockquote> 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. <blockquote type="cite"> 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 </blockquote> >> > </body> </html>