<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 12-01-05 12:01 PM, Colin Walters wrote:
    <blockquote cite="mid:1325782870.13763.24.camel@lenny" type="cite">
      <pre wrap="">On Thu, 2012-01-05 at 17:50 +0100, Cyril Brulebois wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">Gaetan Nadon <a class="moz-txt-link-rfc2396E" href="mailto:memsize@videotron.ca">&lt;memsize@videotron.ca&gt;</a> (05/01/2012):
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">#!/bin/sh
exec xorg-autogen.sh "$@"
</pre>
          </blockquote>
          <pre wrap="">
Note that I will also have to update configure.ac in each module to
mandate the latest version of xorg-macros (as usual):
XORG_MACROS_VERSION(1.17)
</pre>
        </blockquote>
        <pre wrap="">
So you'll have a check in configure.ac to make sure xorg-macros has
xorg-autogen.sh, so that autogen.sh can run it? autogen.sh is what
triggers autoreconf and the look at configure.ac; chicken, egg.</pre>
      </blockquote>
    </blockquote>
    I had a feeling the chicken was coming...<br>
    <blockquote cite="mid:1325782870.13763.24.camel@lenny" type="cite">
      <blockquote type="cite">
        <pre wrap="">
</pre>
      </blockquote>
      <pre wrap="">
Hmm...but how many people

1) Build an xorg module from git </pre>
    </blockquote>
    A lot<br>
    <blockquote cite="mid:1325782870.13763.24.camel@lenny" type="cite">
      <pre wrap="">
2) Are patching a configure.ac or Makefile.am and thus want to rerun
autotools in a package built from tarball</pre>
    </blockquote>
    A few<br>
    <blockquote cite="mid:1325782870.13763.24.camel@lenny" type="cite">
      <pre wrap="">

but can't ALSO trivially update xorg-util-macros?  I'm not too familiar
with the workflow of people who hack on X.org related modules, so it's
an honest question.  </pre>
    </blockquote>
    Indeed, an honest question. Some build video drivers against the
    distro installed headers and libs. Others have pre-canned dev env
    targeted at embedded systems. There aren't too many complaints about
    upgrading xorg-macros, but it better be obvious that it needs to be
    upgraded. No obscure failure to debug.<br>
    <blockquote cite="mid:1325782870.13763.24.camel@lenny" type="cite">
      <pre wrap="">

In GNOME we recommend jhbuild which makes it trivial to pull in the
latest gnome-common git.  But of course we made a common autogen script
years ago, so that module is pretty widespread; e.g. you can install it
via major distribution packages too.

Regardless we could certainly change the patch to all modules to be:

#!/bin/sh
common_autogen=`which xorg-util-autogen.sh 2&gt;/dev/null`
if test -n "$common_autogen"; then
  exec $common_autogen "$@"
else
  # copy&amp;pasted version here
fi</pre>
    </blockquote>
    Now that autogen.sh depends on xorg-macros, we need to move up the
    version check in autogen.sh.<br>
    <br>
    Something like: pkg-config --print-errors --exists "xorg-macros
    &gt;= 1.17"<br>
    <blockquote>would print: Requested 'xorg-macros &gt;= 1.17' but
      version of X.Org Macros is 1.16.0<br>
    </blockquote>
    This would be the minimum version of xorg-macros that this version
    of autogen.sh requires. The rest would be a usual in configure.ac
    (request 1.17, then 6 months later 1.18 and so on.<br>
    <br>
    There is no point in providing a fallback as configure.ac will also
    request 1.17 or even later.<br>
    <blockquote cite="mid:1325782870.13763.24.camel@lenny" type="cite">
      <pre wrap="">

One question someone watching this discussion might be wondering - why
keep an autogen.sh in each module at all?  There are a few reasons, but
an example one is that it allows a module to individually check for say
a buggy automake version that some of its Makefile.am code triggers, and
bail, but still then exec the common autogen.sh.



</pre>
    </blockquote>
    <br>
  </body>
</html>