Re: Stop installing /usr/bin/clang

On Fri, Aug 16, 2019 at 09:47:41AM +0100, David Chisnall wrote:
> 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?
Between /usr/bin/clang and /usr/local/bin/clang.

> The binary that is invoked as clang is from the base system.
Not necessary.

> The binary that is invoked as clang{version number} is from ports.
This is irrelevant.

> 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.
This is irrelevant as well.

You did not read neither review summary nor followups.  clang also
comes from devel/llvm.  Users that want clang do install it, esp. when
version in base is different.

> 
> 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?

I plan to ask for exp run with the patch after some more time to gather
feedback.