Re: Stop installing /usr/bin/clang

On 15/08/2019 17:48, Konstantin Belousov wrote:
 > Please look at https://reviews.freebsd.org/D21060
 > I propose to stop installing /usr/bin/clang, clang++, clang-cpp.
 >
 > It probably does not matter when all your software comes from ports or
 > packages, but is actually very annoying when developing on FreeBSD.
 > In particular, you never know which `clang' is called in the user
 > environment, because it depends on the $PATH elements ordering.

What is the confusion here?  The binary that is invoked as clang is from 
the base system.  The binary that is invoked as clang{version number} is 
from ports.  If the user has built clang from source and has set up 
their path to put that first, then they will get a different clang, but 
there's no way we can stop that kind of behaviour.

For reference, on my machine, I have:

clang <- this one is from the base system
clang60 <- this one if from ports
clang70 <- this one if from ports
clang80 <- this one if from ports
clang-devel <- this one if from ports

Nothing in my PATH order affects this.

The only source of confusion that I regularly encounter comes from the 
fact that FreeBSD packages install clang80, when every other system 
installs clang-8, so I end up having to have a special case in CMake 
logic for finding specific versions of tools like clang-format on FreeBSD.

That said, I don't know what the impact would be on configure scripts if 
we didn't have a clang binary.  CMake seems to run ${CC} -v and parse 
the output, so it's quite happy finding that cc is clang (and the 
specific version).  How do most autoconf things handle this?  Apple 
shipped a gcc symlink to clang for years because, in the absence of a 
gcc binary, a load of programs detected /usr/bin/cc and decided not to 
enable any GNU extensions.  We've managed to avoid having to do that, 
but how many things look for clang, gcc, and cc in the path and enable 
features based on which one they find?

David