This is the mail archive of the
mailing list for the GCC project.
Re: Dealing with compilers that pretend to be GCC
On Fri, 20 Jan 2012, Dave Korn wrote:
OTOH the entire point of autotools is that any toolchain (even GCC itself)
sometimes has bugs or unimplemented features, and you just can't argue with
the principle that the definitive test is always going to be "try and use the
feature and verify if it worked or not". Therefore autoconf tests should not
just test __GNUC__, unless the only thing they're trying to be a test for is
whether __GUNC__ is defined or not.
That's very relevant for packages that are compiled and where you just
install binaries and trivial headers. For libraries where headers contain
non-trivial code (in C++, there may not even be a compiled part to the
library), not so much. You can generate a config.h with autoconf, but then
you need to install it. And if you use several compilers, or several
versions of a compiler, or several sets of options from the same compiler,
you get into a horrible mess. So we need to rely on preprocessor defines
like __GNUC__ to identify what we can do.
We could also write autoconf bits for users of the library to include in
their configure.ac, but most users don't use autoconf for their project,
and with recursive dependencies it would quickly get out of hand.