Any drastic change would have to be done in the head branch. What about keeping ports' compilers as they are, by not using /usr/local/toolchain/* at all.
Then going with the directory for the base system. For instance: /usr/toolchain/bin/, /usr/toolchain/sbin/, and /usr/toolchain/lib/ for shared files. Then using /usr/toolchain/clang/ and /usr/toolchain/gcc/ for specifically needed files? of course the directory name can be abbreviated or otherwise shortened. This suggestion is kind of like the include/ directories. If that's more difficult then, I'll redact my argument. In a way it should be more organized. However, in another way, perhaps it is more upkeep, which I intended to propose the opposite effect. Fri Jun 30 21:13:32 UTC 2017, Mark Millard <markmi at dsl-only.net> wrote: >There is some commonality. Both contexts are based on >earlier Unix and Unix-like hierarchies. And the >commonality helps with making ports and such easier >to support as an example. The types of systems are not >completely independent. >Lots of tools and such are based on knowing current >placements and general properties of the hierarchies. >Reorganizations are a big deal and do not happen >often. >It is also messy for ports to organize things differently >than upstream does. 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). Sat Jul 1 10:01:29 UTC 2017, David Chisnall <theraven at FreeBSD.org> wrote: >Debian does something like this, and it’s a huge pain to work with. The >problem is that toolchains are not self-contained >monolithic components >(though gcc likes to pretend that they are). For example, we want gcc and >clang to use the same >linker, the same C and C++ standard library >implementations, and the same system headers, irrespective of the compiler >>version. Things that actually are private to a compiler are in separate >directories (see /usr/lib/clang, for example). >David _______________________________________________ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
