#93 set CC/CXX/CPP explicitly

[Benjamin Reed]

Attaching a patch that sets CC, CXX, and CPP based on the
tree and the GCC: field. 99% of the ifnk packages already
honor these variables, so it will make things easier for
packagers (just set the GCC field) and for people using distcc
(it will automatically invoke the right compiler, rather than
possibly introducing binary incompat).

[Benjamin Reed]

fink-fullgcc.patch

[David R. Morrison]

Logged In: YES
user_id=271216

This is a big change in the meaning of the GCC field, so I'm
suggesting that we postpone further discussion of it until
after we've got the 10.2-gcc3.3 and 10.3 updates out the door.

[Benjamin Reed]

Logged In: YES
user_id=375

Works for me.

Just posting to put down on paper some of the other things
we discussed in this:

When we have time to breathe, I would like, eventually, to
enforce that all fink packages understand $CC, $CXX, and
$CPP. This would allow us to get rid of the "die and say
run sudo gcc_select", and let us safely use the GCC field as
a flag for what compiler to use, rather than an enforcement
of system state. Packages that don't work with cpp-3.3 can
still set "CPP='gcc3 -E'" manually in CompileScript if they
need to special-case it.

It also means distcc will automatically work because we'll
always be calling the versioned compiler, and it means
ccache will not get possible hash conflicts between building
the same .o file with gcc -> gcc-3.3 and gcc -> gcc3 at
different times.

It's more pedantic, *and* lets us not fail if gcc_select is
set wrong, so I think it's a definite win overall, since
most fink packages already honor these variables.

[Benjamin Reed]

fink-fullgcc.patch (against HEAD 10/16/2003)

[Max Horn]

Logged In: YES
user_id=12935

Regarding ccache: ccache already takes the compiler binary into
account when computing the hash. So it should never get conflicts
due to switching between various gcc versions.

Regarding "this allows us to get rid of gcc_select": hm yes, it
does. But don't forget that this will *not* solve all issues with gcc
3.1 vs 3.3 vs. 2.95.x - the fundamental problem of C++ ABI
incompatibilities of course still remains. Just wanted to make sure
you keep that in mind. :-)

[Max Horn]

I think we should close this as out of date: We nowadays have compiler_wrapper to take care of issues like this, and at the same time, this patch would affects virtually every package, so it would be a major undertaking to realize this. Maybe if we had done this at the start of the new 10.7 tree... but even then it would be a major hardship.
If people feel that we really should go with something like this patch, then I think at the very least we should put it into a new InfoN level, as this marks a major semantical changes.