How about going with a toolchain directory for the base system only. It would use shared files, and have subdirectories specific to clang, gcc, or other compiling components or versions. This way it is both modular and organized.
For instance: /usr/toolchain/bin/, /usr/toolchain/sbin/, and /usr/toolchain/lib/ can be used for shared files. /usr/toolchain/clang/, /usr/toolchain/gcc/, etc, and their (lib, sbin, bin, include) subdirectories can be used for specifically needed files. The old directories can be softlinked to there. Any drastic changes can only be tried in the head branch. Port compilers should definitely be left alone, by not using /usr/local/toolchain/* at all. 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). Fri Jun 30 21:13:32 UTC 2017, Mark Millard <markmi at dsl-only.net> wrote: >commonality helps with making ports and such easier >to support as an example. The types of systems are not >completely independent. ... >Reorganizations are a big deal and do not happen >often. ... >It is also messy for ports to organize things differently >than upstream does. _______________________________________________ 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"
