#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
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: | new → closed |
Duplicate of #30434.
comment:7 Changed 10 years ago by petrrr
Cc: | Peter.Danecek@… removed |
---|
I brought this up originally and was mainly concerned with consistency, i.e. avoiding that using generic
cc
andc++
would result in using potentially very different compilers. The following is what happens currently on my system:Now thinking about this in detail, I believe that there is a valid point that
cc
andc++
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;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?