[PATCH 2/2] libXft: remove AC_PROG_CC as it overrides AC_PROG_C_C99

[Gaetan Nadon]

On Wed, 2011-01-19 at 12:51 -0800, Dan Nicholson wrote:

> 
> This seems like more of a problem with the macros. I don't know why
> XORG_STRICT_OPTION doesn't just AC_REQUIRE AC_PROG_CC so that we don't
> get these kinds of issues.

I have not found a way to avoid these issues. The last call wins.
If C99 is invoked before AC_REQUIRE C89, C89 will win simply because
it is not C99. They don't know about each other, even if some of the
work they
do is cached and reused by the other.

>  However, for this particular case I think
> it would be better if we just moved the XORG_DEFAULT_OPTIONS call
> below AC_PROG_CC.

The statements become order sensitive, which is hard to maintain, even
when commented. The day will come where there will be a dead lock.

>  If we comment or remove AC_PROG_CC, then it becomes
> really unclear that we're getting it implicitly through
> XORG_DEFAULT_OPTIONS.
> 

This is also true for any macro that is being invoked from
XORG_DEFAULT_OPTIONS.

The XORG_STRICT_OPTION was intended to "enforce" C99 by virtue of
inclusion
in configure.ac. It ceased to be "optional" once it got included in
XORG_DEFAULT_OPTIONS.

Other comments from reviewers so far indicate there is no objections to
C99,
with some pros and cons.

The reason why AC_PROG_CC are removed is for the module to be compiled
C99.

If we find something better to do, it should be applied to all 240
modules, unless there
is a reason to configure the modules with different compiler levels.

To find out which version it is compiled with: 

        grep "^CC=" `find . -name config.log -type f -print`


For a C99:

        CC='gcc -std=gnu99'


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110119/a5286198/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110119/a5286198/attachment.pgp>