Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#43734 closed defect (duplicate)

*gcc*, gcc_select: add symlink for ${prefix}/bin/cc

Reported by: Ionic (Mihai Moldovan) Owned by: mww@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: ryandesign (Ryan Carsten Schmidt), petrrr
Port: gcc_select

Description

As reported on the macports-users mailing list, (mport)select should also create a symlink for ${prefix}/cc to the selected GCC version.

As the select function only takes a list of sources and targets and no port is currently installing a ${prefix}/bin/cc-mp-${version} file, I see two ways to tackle this:

  • add a symlink in destroot for ${destroot}${prefix}/bin/cc-mp-${version} to ${destroot}${prefix}/bin/gcc-mp-${version} (or just plain copy the binary) and add both bin/cc and bin/cc-mp-$version to gcc_select and all select files in the *gcc* ports
  • add an entry for bin/cc in gcc_select's base file and bin/gcc-mp-$version in all select files in the *gcc* ports.

What are your thoughts?

Change History (7)

comment:1 Changed 10 years ago by mf2k (Frank Schima)

Cc: mww@… removed
Owner: changed from macports-tickets@… to mww@…

comment:2 Changed 10 years ago by petrrr

I brought this up originally and was mainly concerned with consistency, i.e. avoiding that using generic cc and c++ would result in using potentially very different compilers. The following is what happens currently on my system:

petr% which cc
/usr/bin/cc
petr% which c++
/opt/local/bin/c++

Now thinking about this in detail, I believe that there is a valid point that cc and c++ might use any C compiler, as valid target, not only one of the GCC versions. This would imply a slightly more complicated solution than the one proposed above.

  • gcc_select would not provide the ${prefix}/bin/c++ link anymore;
  • instead a new cc_select would provide a possibility to select where ${prefix}/bin/cc and ${prefix}/bin/c++ should point to, with the option to select among all valid C compilers (gcc/dragonegg, clang, system, etc.)

This is probably the cleanest way to deal with this. Too complicated?

comment:3 Changed 10 years ago by Ionic (Mihai Moldovan)

A compiler_select target doesn't sound bad. But it shouldn't be limited to bin/cc{,++} only. Instead, it should (also) set up

  • bin/cc
  • bin/c++
  • bin/cpp
  • bin/gcc
  • bin/g++

to really have some consistency in there. bin/gcc and bin/g++ may look weirdly when not provided by gcc but instead, e.g., clang, but "that's what Apple does" as well and it makes sense, as clang and others are (mostly) GCC-compliant, and that's what matters.

Likewise, those links mentioned above should be removed from the *gcc* ports' select files (that is, those files installed in ${prefix}/etc/select/gcc/) and moved, still within the *gcc* ports, to the compiler_select group in ${prefix}/etc/select/compiler/.

A new port for compiler_select is then providing base (and basically the other stuff gcc_select and clang_select already provide for internal compilers not installed by MacPorts.)

What about this?

comment:4 Changed 10 years ago by petrrr

IMO, I do not think, gcc and g++ should be moved from gcc_select. The *_select ports are about where some common names, e.g. ipython or gcc point (link) to, not necessary about to which ports, e.g. gcc48` they have to point.

So having a gcc_select port and port select gcc ... around which would not influence the gcc is contradictory. Instead, one could consider -- if this is really what we want -- that port select gcc ... can be set to some clang versions as well. To my understanding there is no cpp binary is provided by clang.

comment:5 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: duplicate
Status: newclosed

Duplicate of #30434.

comment:6 Changed 10 years ago by petrrr

Cc: petr@… added

Cc Me!

comment:7 Changed 10 years ago by petrrr

Cc: Peter.Danecek@… removed
Note: See TracTickets for help on using tickets.