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