Opened 9 years ago

Closed 3 years ago

#48647 closed defect (fixed)

`port select gcc` sets default C++ compiler

Reported by: john@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.3.3
Keywords: Cc: mww@…, ryandesign (Ryan Carsten Schmidt), petrrr, larryv (Lawrence Velázquez), raimue (Rainer Müller), jeremyhu (Jeremy Huddleston Sequoia)
Port: gcc_select

Description

Running (say) port select gcc mp gcc5 creates /opt/local/bin/cpp and c++ symlinks to the specified version of GCC. This is not the behaviour I expected.

It seems like this command should set the default version invoked with g++, but not "promote" GCC to be the default compiler. That is, it would create symlinks for g++, gcc etc, but not generic names like c++. This would be consistent with (for example) clang_select, which creates a clang++ symlink but not c++.

Change History (6)

comment:1 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added

I think I agree. It was previously brought up in #30434 where it was requested that "port select gcc" should also make a symlink /opt/local/bin/cc. This was rejected. So, correspondingly, we should also not be setting /opt/local/bin/c++, as you say.

Perhaps the reason why this discrepancy exists in the first place is that the gcc ports do actually install programs with "gcc", "g++" and "c++" in the name (where the "g++" and "c++" programs are identical), but do not install a program with just "cc" in the name.

Usually, changing the list of files "port select" affects involves changing and increasing the revision of every port that can be selected. That would mean revbumping every gcc port, which would be a shame because that would be a lot of unnecessary rebuilding to just change a couple lines in a text file. It would be great if we could avoid that.

I imagine the gcc_select port will need to be updated and revbumped as well. But I'm not sure if we have a good way to handle this for existing users. I don't think the select portgroup anticipated the situation where a file is removed from the set of selected files. We may have to have a post-activate block that deletes /opt/local/bin/c++ if it exists and is not registered to a port.

I'm not certain what we should be doing about /opt/local/bin/cpp, since there is no GNU-specific equivalent (there is no "gpp"). Some ports may be running the C preprocessor as "$CC -E", but some may expect "cpp" to exist. Maybe it should be a handled by a separate "cpp_select" port?

comment:2 Changed 9 years ago by petrrr

Cc: petr@… added

Cc Me!

comment:3 Changed 8 years ago by larryv (Lawrence Velázquez)

Cc: larryv@… added

Cc Me!

comment:4 Changed 8 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: raimue@… jeremyhu@… added

Three gcc ports are outdated right now (gcc49, gcc6, gcc7), and as I update them, I would like to finally do something about this issue. I would like to remove "c++" from gcc select. And I think I will remove "cpp" as well, if there are no objections. Perhaps I will change it to "gcpp".

At the same time, I am considering introducing a "cc" or "compiler" select group, as Rainer suggested, to select "cc", "c++" and "cpp". However, Jeremy advised against it. Can you elaborate?

comment:5 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)

First off, I agree 100% with removing cc and c++ from the gcc select group.

I'm not too opposed to a cc/c++ port group, but but we should consider whether or not we want cpp to be in there or as yet another port group. I could see cases where someone would want clang to be cc and tradcpp to be cpp.

comment:6 Changed 3 years ago by rubendibattista (Ruben Di Battista)

Resolution: fixed
Status: newclosed

In b359be07684154e7c42f3313dfe55a5ed1c80bde/macports-ports (master):

gcc: Remove c++ symlink

Fix #48647

Note: See TracTickets for help on using tickets.