Date: Sat, 15 Jul 2017 18:12:07 -0600 From: Warner Losh <imp@bsdimp.com> To: Sid <sid@bsdmail.com> Cc: "freebsd-toolchain@FreeBSD.org" <freebsd-toolchain@freebsd.org> Subject: Re: suggestion for toolchain to have its own directories Message-ID: <CANCZdfqNtTxLiP1Lea-rpcbTpeApbJg=V2xPz7uHaDBXCq1tpQ@mail.gmail.com> In-Reply-To: <trinity-bc87df55-8a78-40d5-9636-372de83ec91e-1500160899153@3capp-mailcom-lxa10> References: <trinity-bc87df55-8a78-40d5-9636-372de83ec91e-1500160899153@3capp-mailcom-lxa10>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jul 15, 2017 at 5:21 PM, Sid <sid@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, o= r > 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 a= ll. > 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=E2=80=99s a huge pain to work wi= th. 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 compile= r > >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- > unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqNtTxLiP1Lea-rpcbTpeApbJg=V2xPz7uHaDBXCq1tpQ>