suggestion for toolchain to have its own directories
Warner Losh
imp at bsdimp.com
Sun Jul 16 00:12:08 UTC 2017
On Sat, Jul 15, 2017 at 5:21 PM, Sid <sid at bsdmail.com> wrote:
> 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.
>
And non-standard. Auxiliary tools that know about toolchains would need to
be modified. That's a losing fight.
> 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.
>
Old directories won't cut it.
> 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.
>
Yea, I think this is a bad idea. There's no upside to it, other than
appealing to somebody's sense of what's organized. The downsides are plenty
and create a lot of work for us just to get back to where we are today.
Unless there's a truly compelling reason to do this, my vote, and loud
shouting voice, says don't do it.
Warner
>
> 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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "freebsd-toolchain-
> unsubscribe at freebsd.org"
More information about the freebsd-toolchain
mailing list