>>>>> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Hello!
>> Nevertheless, what I don't really understand is the default to
>> "$HOST_CC". Why should BUILD_CC default to HOST_CC? How could
>> using a HOST_CC, which I understand as a compiler for the HOST we
>> target, helps understanding the nature of the build system.
Pavel> Because I assumed it's a long-standing tradition to name the
Pavel> compiler for the build system HOST_CC.
Aaaarg :) Traditions sox :)
Pavel> It was my proposal to check for HOST_CC. It's fine with me if
Pavel> you change this name provided that the change is properly
Pavel> documented.
Now that you confirmed the meaning of HOST_CC I understand perfectly
well your point. In fact, why is it that we need to give a HOST_CC to
config.guess? Can't it AC_CHECK_PROG a gcc or a cc itself and check
by itself if it is a cross compiler or not?
It would make it be more autonomous.
Also, something I've never quite understood, very related to the fears
of Paul D. Smith wrt cross compilation's sad effects, is the fact that
we never based our thinking on the name of the compiler to guess if
we're cross compiling or not.
Sure it is not *right* in the absolute to depend on the name of the
compiler, but are there really envs in which `cc' or `gcc' is a cross
compiler? Can't we say `if something named cc or ?cc etc. fails to
compile-link-run then it is probably not a cross compilation envs, but
more probably a real problem with the compiler'?
Pavel> Since the forthcoming Autoconf 2.15 (or should it be 2.50?)
Pavel> will be very different from 2.13 the idea of using BUILD_CC
Pavel> seems to be justified.
Hm, I don't see how this issue is related to Autoconf. It's not even
documented, AFAICS. Nevertheless, BUILD_CC or even NATIVE_CC seems
more attractive than HOST_CC :)
Akim
