There's possibly a few good reasons. For instance, better organization means easier troubleshooting and finding bugs. It could mean easier maintenance and upgrading. It would also be easier to know for sure which file is being used: the one in the base system, or the one from ports, when it is assumed one or the other is used. A checksum can be run on the directory to find cases of corruption of compiling tools. src.conf can also be split up and simplified to another file that is only for compiling tools. They are looking at making much of the base system into packages, and the simplicity would reduce the need for it, or would simplify it. It would also make it easier for a meta-distribution from the install. Of course, a few of the above can be done without putting toolchains in their own modular directories. You are the professionals, who know what it would take, and how much trouble it would be versus any benefits. If it is worth it, perhaps the time isn't now. The time it would make sense to me, is to either replace or simplify the proposal of using packages as proponents for the base distribution. There would be no rush, but if the idea starts to make better sense or appeal to developers, then perhaps that idea can be thought about then. I still think it's a good idea, but I don't see a need to do anything at least in the near term.
Thank you all for your responses. > On Sun, Jul 16, 2017 at 00:12:08 UTC 2017, Warner Losh <imp at bsdimp.com> > wrote: >> On Sat, Jul 15, 2017 at 23:34:37 UTC 2017, 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. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "[email protected]"
