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