<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"><memsize@videotron.ca></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>/dev/null`
if test -n "$common_autogen"; then
exec $common_autogen "$@"
else
# copy&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
>= 1.17"<br>
<blockquote>would print: Requested 'xorg-macros >= 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>