Re: Stop installing /usr/bin/clang
On 16/08/2019 10:10, Konstantin Belousov wrote:
You did not read neither review summary nor followups.
This is needlessly insulting and this kind of attitude from you towards
people on the mailing lists is one of the main reasons that my
engagement with the FreeBSD project tends to be in brief bursts. If
this were a one-off, then I would be happy to assume that you were
unusually stressed, but this is a long-term repeated pattern of behaviour.
I was not aware that devel/llvm was anything other than a meta-port that
installed the latest devel/llvm{version} (I have only ever installed the
packages when I need a specific version and so do not have the
devel/llvm port installed). You could have clarified that. Instead,
you chose to launch a personal attack.
You are not Linus and the FreeBSD project does not need a Linus.
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"
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@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
--
Rod Grimes rgri...@freebsd.org
___
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"
Re: Stop installing /usr/bin/clang
On Fri, Aug 16, 2019 at 02:14:38AM -0700, Rodney W. Grimes wrote:
> > On Fri, Aug 16, 2019 at 08:57:13AM +0300, nonamel...@ukr.net wrote:
> > > I see the same thing with base?/usr/bin/ld and?/usr/local/bin/ld from
> > > binutils.
> > Yes but a direct ld use is very rare. When it is needed, usually the
> > level of hackery applied is already high enough for the user to already
> > know what she does. I did not see it causing issues practically, while
> > multiple clangs in the path cause real problems.
>
> Though I have accepted the change, I have now heard this "multiple foo
> in path" argument twice, could you please elaborate on it?
I already did that more than once. Please read the review.
>
> If /usr/bin /bin are first I should get base stuff,
> if /usr/local/bin are first I should get local stuff,
> what exactly is this "real problems" your refering too?
You cannot mandate the path elements order for user, there are multiple
conflicting requirements which create loop in the elements ordering.
Removing clang from /usr/bin removes one of the requirement.
People have to put ~/bin in front of their $PATH and create symlink,
which raises questions why should they do that, and makes awful experience
for starting developing on FreeBSD.
>
> Is it that something is flipping paths around? If so that
> should be fixed! People have been using path to pick which
> overload order they prefer for decades, and if we have some
> how broken this.. well that should get fixed asap, not
> removing stuff out of base because something is broken by
> incorrect path manipulations.
>
> Regards,
> Rod
> > > --- Original message ---
> > > From: "Konstantin?Belousov"?
> > > Date: 15?August?2019,?19:48:37
> > >
> > > 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.
> > >
> > > To clear some confusion: this has nothing to do with not installing
> > > compiler from base, /usr/bin/c{c,++,pp} are still there after the change
> > > is applied. It only to make clang on par with gcc, and to remove one
> > > thing that was quite time-consuming in multi-target environment for me
> > > during porting something large in FreeBSD userspace.
> > > ___
> > > 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"
> > ___
> > 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"
> >
> >
>
> --
> Rod Grimes rgri...@freebsd.org
___
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"
Re: Stop installing /usr/bin/clang
> On Fri, Aug 16, 2019 at 08:57:13AM +0300, nonamel...@ukr.net wrote:
> > I see the same thing with base?/usr/bin/ld and?/usr/local/bin/ld from
> > binutils.
> Yes but a direct ld use is very rare. When it is needed, usually the
> level of hackery applied is already high enough for the user to already
> know what she does. I did not see it causing issues practically, while
> multiple clangs in the path cause real problems.
Though I have accepted the change, I have now heard this "multiple foo
in path" argument twice, could you please elaborate on it?
If /usr/bin /bin are first I should get base stuff,
if /usr/local/bin are first I should get local stuff,
what exactly is this "real problems" your refering too?
Is it that something is flipping paths around? If so that
should be fixed! People have been using path to pick which
overload order they prefer for decades, and if we have some
how broken this.. well that should get fixed asap, not
removing stuff out of base because something is broken by
incorrect path manipulations.
Regards,
Rod
> > --- Original message ---
> > From: "Konstantin?Belousov"?
> > Date: 15?August?2019,?19:48:37
> >
> > 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.
> >
> > To clear some confusion: this has nothing to do with not installing
> > compiler from base, /usr/bin/c{c,++,pp} are still there after the change
> > is applied. It only to make clang on par with gcc, and to remove one
> > thing that was quite time-consuming in multi-target environment for me
> > during porting something large in FreeBSD userspace.
> > ___
> > 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"
> ___
> 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"
>
>
--
Rod Grimes rgri...@freebsd.org
___
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"
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.
___
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"
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
___
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"
Re: Stop installing /usr/bin/clang
On Fri, Aug 16, 2019 at 08:57:13AM +0300, nonamel...@ukr.net wrote:
> I see the same thing with base /usr/bin/ld and /usr/local/bin/ld from
> binutils.
Yes but a direct ld use is very rare. When it is needed, usually the
level of hackery applied is already high enough for the user to already
know what she does. I did not see it causing issues practically, while
multiple clangs in the path cause real problems.
>
> --- Original message ---
> From: "Konstantin Belousov"
> Date: 15 August 2019, 19:48:37
>
> 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.
>
> To clear some confusion: this has nothing to do with not installing
> compiler from base, /usr/bin/c{c,++,pp} are still there after the change
> is applied. It only to make clang on par with gcc, and to remove one
> thing that was quite time-consuming in multi-target environment for me
> during porting something large in FreeBSD userspace.
> ___
> 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"
___
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"
Re: Stop installing /usr/bin/clang
I see the same thing with base /usr/bin/ld and /usr/local/bin/ld from binutils.
--- Original message ---
From: "Konstantin Belousov"
Date: 15 August 2019, 19:48:37
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.
To clear some confusion: this has nothing to do with not installing
compiler from base, /usr/bin/c{c,++,pp} are still there after the change
is applied. It only to make clang on par with gcc, and to remove one
thing that was quite time-consuming in multi-target environment for me
during porting something large in FreeBSD userspace.
___
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"
___
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"
Stop installing /usr/bin/clang
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.
To clear some confusion: this has nothing to do with not installing
compiler from base, /usr/bin/c{c,++,pp} are still there after the change
is applied. It only to make clang on par with gcc, and to remove one
thing that was quite time-consuming in multi-target environment for me
during porting something large in FreeBSD userspace.
___
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"
