#93 set CC/CXX/CPP explicitly


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

    Benjamin Reed - 2003-10-13


  • David R. Morrison

    Logged In: YES

    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

    Benjamin Reed - 2003-10-14

    Logged In: YES

    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

    Benjamin Reed - 2003-10-16

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

  • Max Horn

    Max Horn - 2003-10-17

    Logged In: YES

    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

    Max Horn - 2011-10-28

    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.


Log in to post a comment.