On Fri, Jan 04, 2013 at 04:22:05PM -0500, Gaetan Nadon wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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. > 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 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with undefined - http://www.enigmail.net/ > > iEYEARECAAYFAlDnR/AACgkQubv1WfueyfxKLQCfSOwOoRmXSkYxpx1APTPEX/id > SZgAoIx2TIY/2cPRwDEwOxnCSlfqUlf+ > =AulD > -----END PGP SIGNATURE----- > _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
