[PATCH macros] Cache the results of checking compiler flag support in XORG_TESTSET_CFLAG
jon.turney at dronecode.org.uk
Tue Jan 17 09:14:57 PST 2012
On 12/01/2012 21:50, Gaetan Nadon wrote:
> On 12-01-12 11:49 AM, Jon TURNEY wrote:
>> Since checking all those warning flags takes an amount of time I find irritating,
>> here is an attempt at caching the results of checking compiler warning flag support
>> A couple of aspects which need definitely need review or testing:
>> * I've tried to get things right when not the first flag in the list of alternates is
>> supported, but this really needs testing with a compiler other than gcc
> I used an unrecognised flag such as "-i" and moved it around in the list.
>> * The cache variable naming policy is a bit opaque me, so the names used may need corecting
>> * I've tried to be careful, but who knows what portability sins I have committed :-)
> I did not see anything suspicious, everything is autoconf blessed.
Thanks for the review.
>> +dnl Some hackery here since AC_CACHE_VAL can't handle a non-literal varname and
>> +dnl flag may contains spaces as it may contain multiple flags, but a cacheid can't
>> AC_MSG_CHECKING([if $CC supports ]flag)
>> - AC_LINK_IFELSE([AC_LANG_PROGRAM([int i;])],
>> - [supported=yes], [supported=no])
>> - AC_MSG_RESULT([$supported])
>> + cacheid=`AS_ECHO_N([xorg_cv_cc_flag_]flag) | $SED 's/ /_/'`
> Can you have a look at:
> # This outputs "Have it!".
> header="sys/some file.h"
> eval AS_TR_SH([HAVE_$header])=yes
> if test "x$HAVE_sys_some_file_h" = xyes; then echo "Have it!"; fi
> This example seem to indicate you would not need to replace spaces with
> underscore yourself.
You are correct, AS_TR_SH applies a suitable transformation that the result is
a valid shell variable name, so I don't need to use sed at all here.
Updated patch with that removed attached.
> I have one question regarding how you use the cache file. You are aware
> that some of the Automake variables we create in the various xorg
> modules do not have a unique name across packages. For example. in the
> driver section, PKG_CHECK MODULES(XORG, ...) is very common. The
> variable pkg_cv_XORG_LIBS does not have the same value for all drivers.
> Using a cache file will almost always return the wrong value. How do you
> work around this issue?
At the moment, I am ignoring this issue, and just use a single cache file when
jhbuilding the whole Xorg stack. This is probably the wrong thing to do. :-)
I don't have a specific issue with the pkg_cv_XORG_LIBS variable for drivers,
as I generally don't build the drivers, not being of much use on my platform
Also, looking at pkg.m4, if I am reading it correctly, it seems to me that
pkg_cv_ variables aren't used like normal cache variables: pkg-config is run
(once) on each configure run. This might explain why I don't have more
problems with my sloppy approach.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the xorg-devel