#93 set CC/CXX/CPP explicitly

open
nobody
None
5
2003-10-13
2003-10-13
Benjamin Reed
No

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).

Discussion

  • Benjamin Reed
    Benjamin Reed
    2003-10-13

    fink-fullgcc.patch

     
    Attachments
  • 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
    Benjamin Reed
    2003-10-14

    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
    Benjamin Reed
    2003-10-16

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

     
    Attachments
  • Max Horn
    Max Horn
    2003-10-17

    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
    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.