Date: Sun, 2 Jul 2017 03:53:34 +0200 From: Sid <sid@bsdmail.com> To: freebsd-toolchain@freebsd.org Subject: Re: suggestion for toolchain to have its own directories Message-ID: <trinity-71406ad0-e231-4ea3-a65b-a83d0e85860d-1498960414082@3capp-mailcom-lxa04>
next in thread | raw e-mail | index | archive | help
Any drastic change would have to be done in the head branch=2E What about keeping ports' compilers as they are, by not using /usr/local/t= oolchain/* at all=2E Then going with the directory for the base system=2E For instance: /usr/to= olchain/bin/, /usr/toolchain/sbin/, and /usr/toolchain/lib/ for shared file= s=2E Then using /usr/toolchain/clang/ and /usr/toolchain/gcc/ for specifica= lly needed files? of course the directory name can be abbreviated or otherw= ise shortened=2E This suggestion is kind of like the include/ directories= =2E If that's more difficult then, I'll redact my argument=2E In a way it s= hould be more organized=2E However, in another way, perhaps it is more upke= ep, which I intended to propose the opposite effect=2E Fri Jun 30 21:13:32 UTC 2017, Mark Millard <markmi at dsl-only=2Enet> wrot= e: >There is some commonality=2E Both contexts are based on >earlier Unix and Unix-like hierarchies=2E And the >commonality helps with making ports and such easier >to support as an example=2E The types of systems are not >completely independent=2E >Lots of tools and such are based on knowing current >placements and general properties of the hierarchies=2E >Reorganizations are a big deal and do not happen >often=2E >It is also messy for ports to organize things differently >than upstream does=2E So things like lang/gcc7-devel are >unlikely to go to the effort of being significantly >different when the commonality covers most of the >placements already (at least for default configurations)=2E Sat Jul 1 10:01:29 UTC 2017, David Chisnall <theraven at FreeBSD=2Eorg> wr= ote: >Debian does something like this, and it=E2=80=99s a huge pain to work wit= h=2E The problem is that toolchains are not self-contained >monolithic com= ponents (though gcc likes to pretend that they are)=2E For example, we wan= t gcc and clang to use the same >linker, the same C and C++ standard librar= y implementations, and the same system headers, irrespective of the compile= r >version=2E Things that actually are private to a compiler are in separa= te directories (see /usr/lib/clang, for example)=2E >David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?trinity-71406ad0-e231-4ea3-a65b-a83d0e85860d-1498960414082>