Date: Mon, 17 Aug 2015 09:15:50 -0700 From: Dieter BSD <dieterbsd@gmail.com> To: freebsd-hackers@freebsd.org Subject: Re: Sparc64 support Message-ID: <CAA3ZYrD0t=B62pH4GrwSCthdkJLMo0b5vE7WeMOaozD_g0n_vQ@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Jordan: > external toolchain Suggestion: can we get away from "internal" toolchain and "external" toolchain, and set things up to make it easy to have multiple equal toolchains? And an easy way for a user to select which one (and which version) they want to use. Much like setting $EDITOR. Each arch would have a default toolchain in case $TOOLCHAIN isn't set. Bonus points if power toolchain users can easily mix&match pieces from different toolchains. And an easy way to add options. (Example: Back when most code was written assuming all the world is ILP32, I wrote a wrapper that added some compiler warnings for prototypes and such, making it easier to port code to LP64.) Doesn't have to be environment variables, could be a toolchain config file, whatever. The NasaBSD story as it was told to me: 20 years ago, NASA employed many of the NetBSD engineers. NetBSD was very high quality, well thought out, and portable. Not perfect (NetBSD's FFS was never as good as FreeBSD's, (but FreeBSD isn't very useful if it doesn't run on your arch)), but pretty close. Did everything I needed at the time, and nearly no bugs. PRs actually got fixed!!! Hard to imagine these days. The packaging was great. Toolchain was a seperate tar file. Text processing was a seperate tar file, Several other lumps of stuff were seperate tar files. Want to build a minimal machine, like a firewall? Just install kernel, base, and etc. Want everything? Just unpack several tar files. Ether way it was very easy. And the package system for adding third party things worked great. Easy to build cross-arch and/or cross-OS, even if the host OS has no support for the target arch. (I've done it, it worked.) Then these engineers got jobs elsewhere, and NetBSD started going downhill. PRs started getting ignored, or closed for bogus reasons. Essential hardware not supported. More bugs. (FreeBSD has these same problems.) They are even ripping out essential features (for bogus reasons). So NasaBSD is a nickname for early NetBSD. > Even NetBSD, which has long had the motto [crap deleted] of course it > runs NetBSD [crap deleted] (as if the answer was so obvious as to be > unworth the question) NetBSD used to run on pretty much everything. > has been retiring architectures left and right Just part of their slide downhill. > your software will be a collection of burdensome conditionals > and weird constructs I've seen that in 3rd party software. I don't recall seeing it in NetBSD. But given what's been going on there, the recent stuff probably has some. BTW, Attempting to read text with non-ASCII crap sprinkled throughout for no obvious reason is burdensome as well. Extra characters for other languages are one thing, but that doesn't appear to be the case here. Pasting it into my editor results in a mangled mess, which is burdensome to unmangle.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAA3ZYrD0t=B62pH4GrwSCthdkJLMo0b5vE7WeMOaozD_g0n_vQ>