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.
--lyndon
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers