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.

Why is that a confusion?  Any installed port that overloades
a base system component expects to do exactly that type of thing.
Why is clang special in this respect?

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

Exactly what is installed from devel/llvm that was not
covered below as clang-devel?  And why is it any different
than any other port of clang listed below?

> > 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.
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> 

-- 
Rod Grimes                                                 rgrimes_at_freebsd.org