Date: Fri, 16 Aug 2019 12:10:25 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: David Chisnall <theraven@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: Stop installing /usr/bin/clang Message-ID: <20190816091025.GO2738@kib.kiev.ua> In-Reply-To: <03b695ff-afdb-85db-d1d3-b62111c346a9@FreeBSD.org> References: <20190815164815.GK2738@kib.kiev.ua> <03b695ff-afdb-85db-d1d3-b62111c346a9@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190816091025.GO2738>