[PATCH libXi multitouch 3/4] Define macros for unstable protocol development
Gaetan Nadon
memsize at videotron.ca
Sat Sep 17 15:31:01 PDT 2011
On Sat, 2011-09-17 at 09:54 -0700, Chase Douglas wrote:
> On 09/17/2011 06:53 AM, Gaetan Nadon wrote:
> > On Sat, 2011-09-17 at 06:52 +1000, Peter Hutterer wrote:
> >> On Wed, Sep 14, 2011 at 10:33:56PM -0700, Chase Douglas wrote:
> >> > Signed-off-by: Chase Douglas <chase.douglas at canonical.com <mailto:chase.douglas at canonical.com>>
> >> > ---
> >> > configure.ac | 3 +++
> >> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >> >
> >> > diff --git a/configure.ac b/configure.ac
> >> > index 6c2f731..f3d6d8e 100644
> >> > --- a/configure.ac
> >> > +++ b/configure.ac
> >> > @@ -39,6 +39,9 @@ if ! test "x$UNSTABLE_LIB" = xyes; then
> >> > AC_MSG_ERROR([This branch contains elements which have not yet been finalised. When this branch is updated, you will probably need to recompile both the any clients using the library, and may experience crashes or undefined behaviour if you do not.])
> >> > fi
> >> >
> >> > +# Define macros for compiling with unstable protocols
> >> > +AC_SUBST(CFLAGS, "-DXINPUT2_1_USE_UNSTABLE_PROTOCOL -DXINPUT2_2_USE_UNSTABLE_PROTOCOL")
> > CFLAGS is a user environment and should never be set in configure.ac. In
> > some case it is, for a configure test, but restored to the original
> > value. Refer to Automake documentation for a complete discussion on env
> > variable usage.
>
> A couple points:
>
> * This is only temporary while the protocol is under development. It
> will not be part of any official libXi release.
I suppose it goes in git master, so it makes no difference to me. It is
expose in broad day light for any one to conclude that it is ok to do
and replicate in some of the other 240 packages.
>
> * When I have used AC_SUBST before, it has only appended flags to the
> CFLAGS env var. This is exactly what we want.
And that maybe exactly what someone else does not want. The way I
understand Automake, is that the user is king and must have the final
word. This of course might conflict with the developer who wants to
enforce certain flags.
Note that CFLAGS is written after AM_CFLAGS to uphold the user priority
over the configuration.
>
> * I can't find any documentation providing guidelines, so if you have
> any please share :).
I was in a hurry to leave, sorry. Here it is:
http://www.gnu.org/software/automake/manual/automake.html#User-Variables
Some Makefile variables are reserved by the GNU Coding Standards
for the use of the “user”—the person building the package.
For instance, CFLAGS is one such variable.
http://www.gnu.org/software/automake/manual/automake.html#Flag-Variables-Ordering
Follow the links for more discussion. Several xorg packages were setting
CFLAGS in configure.ac and patches have been submitted and reviewed
multiple times by people more knowledgeable than I am. That's how I got
my current understanding. Basically, I was educated by reviewers on this
list.
Unless I have misunderstood Automake, the proper way to handle this
situation is to create a new variable in configure.ac and add it to
AM_CFLAGS in the makefile. I'd be curious to know if the motivation was
to ensure the builder does not change the flags or if it was done
because it is convenient and has always been working.
Thanks for listening, and greetings to all the folks at Canonical.
Gaetan
PS One patch example from Debian in libXfont:
commit f859a76b0f325b07952ad1c5c818318307c589b0
Author: Julien Cristau <jcristau at debian.org>
Date: Tue Nov 4 19:24:29 2008 +0100
Don't clobber CFLAGS in configure
This lets the user set CFLAGS when running make.
>
> Thanks!
>
> -- Chas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110917/ac08ec26/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110917/ac08ec26/attachment.pgp>
More information about the xorg-devel
mailing list