[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Dodgy $LINK in generated Makefile

From: Lyndon Nerenberg
Subject: Re: [Nmh-workers] Dodgy $LINK in generated Makefile
Date: Fri, 1 Feb 2013 14:37:09 -0800

> Well, let me ask this ... is it actually a problem?

It manifests right now in the warning about -ansi that clang generates during 
the link stage.

>  Or just a stylistic
> issue?  I ask because I'm reluctant to change the default LINK rules
> that Automake sets up.

You could blame either side on this one, I guess.  But back in the day there 
was an intentional distinction between CFLAGS and LDFLAGS, even when $CC was 
used to invoke the linker.  You would construct $CFLAGS and $LDFLAGS as 
distinct independent objects, even if that meant duplication of flags between 
the two.

> (I have been meaning to switch us over to using AM_CFLAGS instead of
> CFLAGS in configure.ac, but that's a whole other issue :-/)

What we really need is a much smarter determination of the make and model of C 
compiler being used. The world is no longer just gcc -- LLVM is seeing to that. 
 And it's becoming apparent that Oracle doesn't give a flying f*** about cc(1) 
command-line compatibility with anyone else. Quel suprise.

For now I can address the clang -ansi issue by writing a filter for buildbot to 
have it ignore that diagnostic when counting compilation warnings.  But in the 
long run we really need to write our own compiler detection macro that can just 
set CFLAGS and friends in one swell foop based on the (compiler,version) tuple. 
 This current business of probing individual flags with a test compile is 
error-prone in and of itself, and it's dog slow.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]