Stop installing clang, clang++, and clang-cpp hardlinks in /usr/bin.

[kib]

Summary

They conflict with the same binaries installed by devel/llvm, and hide the version of clang that user wanted to install.

The change makes both gcc and clang, as well as g++ and clang++ handled same: they come from ports. Base system compiler is called cc/c++, whatever is it.

Test Plan

Exp run would be needed after the review.

[bdrewery]

Which package provides clang? I don't have a /usr/local/bin/clang on my system.

[kib]

In D21060#462643, @bdrewery wrote:

Which package provides clang? I don't have a /usr/local/bin/clang on my system.

devel/llvm

[cem]

In D21060#462643, @bdrewery wrote:

Which package provides clang? I don't have a /usr/local/bin/clang on my system.

llvm-devel drops a /usr/local/llvm-devel/bin/clang, although not a default prefix.

[kib]

solo% ls -l /usr/local/bin/clang                                              ~
lrwxr-xr-x  1 root  wheel  7 Aug  5 22:10 /usr/local/bin/clang -> clang90
solo% pkg which /usr/local/bin/clang                                          ~
/usr/local/bin/clang was installed by package llvm-90
solo% pkg which /usr/local/bin/clang90                                        ~
/usr/local/bin/clang90 was installed by package llvm90-9.0.0.r1_1

[emaste]

No objection from me

[dim]

I still don't see the problem, but if this is the way people want it, I'm fine with it.

[imp]

I'd personally rather see us bring back something from the past . We had WITH_CLANG_AS_CC which controlled creating cc->clang links. What if we had WITH_CLANG_LINKS or similar that would create clang->cc links and have it default to off? This isn't blocking if there's no support for it, though. I didn't click request changes for this :).

And have you done an EXP run too see what the fallout is? My 'request changes' is a hard no until that's run and any issues resolved.

[kib]

In D21060#462930, @imp wrote:

I'd personally rather see us bring back something from the past . We had WITH_CLANG_AS_CC which controlled creating cc->clang links. What if we had WITH_CLANG_LINKS or similar that would create clang->cc links and have it default to off? This isn't blocking if there's no support for it, though. I didn't click request changes for this :).

See below.

And have you done an EXP run too see what the fallout is? My 'request changes' is a hard no until that's run and any issues resolved.

I stated that exp run is required after the discussion is finished. I see no reason to ask portmgr to spend their time unless there is a clear route to commit the change.

WRT to optional symlinks, I am fine with it as far as defaults are to not have them. The reason for this change is to remove the surprise and the need to answer 'why' questions for people that start developing on FreeBSD. The same group of people are proficient in Linux and they do not have to manipulate $PATH or create symlinks in ~/bin because 'this is how FreeBSD happens to not-handle it' for all the time (it == conflict between base and ports binaries). If symlinks are on by default, this change does not worth the time.

[imp]

In D21060#462958, @kib wrote:

In D21060#462930, @imp wrote:

I'd personally rather see us bring back something from the past . We had WITH_CLANG_AS_CC which controlled creating cc->clang links. What if we had WITH_CLANG_LINKS or similar that would create clang->cc links and have it default to off? This isn't blocking if there's no support for it, though. I didn't click request changes for this :).

See below.

And have you done an EXP run too see what the fallout is? My 'request changes' is a hard no until that's run and any issues resolved.

I stated that exp run is required after the discussion is finished. I see no reason to ask portmgr to spend their time unless there is a clear route to commit the change.

WRT to optional symlinks, I am fine with it as far as defaults are to not have them. The reason for this change is to remove the surprise and the need to answer 'why' questions for people that start developing on FreeBSD. The same group of people are proficient in Linux and they do not have to manipulate $PATH or create symlinks in ~/bin because 'this is how FreeBSD happens to not-handle it' for all the time (it == conflict between base and ports binaries). If symlinks are on by default, this change does not worth the time.

Yea, we'd default to NO. If we do it at all...

Personally, I'd like to see us add a way to compile in /usr/local/* into our compiler paths as that's been a more significant pain point for me than the which clang do I have...

[jhb]

FWIW, gcc4.2.1 does get installed as /usr/bin/gcc on platforms that use it as /usr/bin/cc, and the base/gcc port that installs gcc6 as /usr/bin/cc also installs it as /usr/bin/gcc. I think gcc may be slightly different though in that autoconf scripts tend to look specifically for gcc sometimes instead of cc. I haven't run into similar configure scripts that look specifically for 'clang'. In my experience they look for 'cc' which happens to be clang.

[kib]

In D21060#463035, @jhb wrote:

FWIW, gcc4.2.1 does get installed as /usr/bin/gcc on platforms that use it as /usr/bin/cc, and the base/gcc port that installs gcc6 as /usr/bin/cc also installs it as /usr/bin/gcc. I think gcc may be slightly different though in that autoconf scripts tend to look specifically for gcc sometimes instead of cc. I haven't run into similar configure scripts that look specifically for 'clang'. In my experience they look for 'cc' which happens to be clang.

configure generated by autoconf always looks for gcc first, AFAIR. One of my problematic use cases is 'CC=clang CXX=clang++ ../src/configure' of course.