<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    -----BEGIN PGP SIGNED MESSAGE-----<br>
    Hash: SHA1<br>
    <br>
    On 13-01-03 10:18 PM, Peter Hutterer wrote:<br>
    <span style="white-space: pre;">> On Thu, Jan 03, 2013 at
      03:55:49PM -0800, Alan Coopersmith wrote:<br>
      >> On 01/ 3/13 03:38 PM, Peter Hutterer wrote:<br>
      >>> is there any particular reason we're still generating
      gz and bzip2? <br>
      >><br>
      >> Because we're not hip enough to have replaced gz with xz
      like all the cool kids?<br>
      >><br>
      >> Or because updating the automake flags in 200+
      configure.ac scripts is not fun.<br>
      ><br>
      > just played around with this a bit, looks like a the common
      code for<br>
      > initialising the projects can be moved into a macro, as long
      as AC_INIT is<br>
      > still in configure.ac. which is the project-specific part
      anyway.<br>
      ><br>
      > So a common template could be <br>
      ><br>
      > AC_DEFUN([XORG_DEFAULT_AUTOMAKE],[<br>
      > AC_PREREQ([2.60])<br>
      > AC_CONFIG_SRCDIR([Makefile.am])<br>
      > AC_CONFIG_HEADERS([config.h])<br>
      > AC_CONFIG_AUXDIR(.)<br>
      ><br>
      > AM_INIT_AUTOMAKE([foreign dist-bzip2])<br>
      > AM_MAINTAINER_MODE<br>
      > ])<br>
      ><br>
      > which would make adding options easier in the future.
      switching to xz,<br>
      > changing/removing AM_MAINTAINER_MODE, etc.<br>
      ><br>
      > note, I've only tested this on a simple test project, not
      across all xorg<br>
      > modules.</span><br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    AM_MAINTAINER_MODE should be removed anyway as it was done in
    xserver.  AC_CONFIG_AUXDIR(.) is not needed.<br>
    <br>
    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.<br>
    ||<br>
    <br>
    <span style="white-space: pre;">><br>
      > Cheers,<br>
      > Peter<br>
      ></span><br>
    <br>
    -----BEGIN PGP SIGNATURE-----<br>
    Version: GnuPG v1.4.11 (GNU/Linux)<br>
    Comment: Using GnuPG with undefined - <a class="moz-txt-link-freetext" href="http://www.enigmail.net/">http://www.enigmail.net/</a><br>
    <br>
    iEYEARECAAYFAlDnR/AACgkQubv1WfueyfxKLQCfSOwOoRmXSkYxpx1APTPEX/id<br>
    SZgAoIx2TIY/2cPRwDEwOxnCSlfqUlf+<br>
    =AulD<br>
    -----END PGP SIGNATURE-----<br>
    <br>
  </body>
</html>