Date: Mon, 10 Aug 2015 00:25:40 -0700 From: Jordan Hubbard <jordanhubbard@me.com> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: Dimitry Andric <dim@freebsd.org>, Bill Sorenson <instructionset@gmail.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Kevin Bowling <kevin.bowling@kev009.com>, "K. Macy" <kmacy@freebsd.org> Subject: Re: Sparc64 support Message-ID: <D6FF7F3C-DF1E-4D60-99DB-BCE162A27126@me.com> In-Reply-To: <CAJ-VmonZvFc24NcOdSK8SbpDa8Zt3xjA%2BbLQ6QnKH%2Bc-JmAmpw@mail.gmail.com> References: <CACcTwYmS1c5uoO-WiJQDwgqYAevX7WZ7ZrP297hnOu7cNET3CA@mail.gmail.com> <mq3sg1$bno$1@ger.gmane.org> <CACcTwYnU=E-6sV3yLh3yKUSPZOg7967XV5ToXoSVPuNfOjF7hQ@mail.gmail.com> <CAHM0Q_NEYWxpHCwEdytfY6i9%2BRO2BebezzmenfQ_1c4u7zGrgg@mail.gmail.com> <CACcTwY=DcUREt5nJWo_eJfrB=3sQXBaS6nc%2B07fpZhxARD0zTQ@mail.gmail.com> <20150809215403.GC20238@server.rulingia.com> <6C12EBFE-EAA9-4C12-9F03-1CB2C28C4A6E@me.com> <CACcTwYktQRTqVSr7PRr5huwbVXVu6oCy26TKiAxzf2NiGAcocA@mail.gmail.com> <51EEBC6E-5D85-439D-874D-D223EE045515@me.com> <CAJ-VmomzV0YKQwenwSZv6fMAOUP8TmPs-oyQaM8KTF7Ndhv_%2Bw@mail.gmail.com> <926DDA42-8883-4AB4-B229-D44387FF5C6B@me.com> <CAJ-VmokHCW8MawfVC_1z2SZ7hfX4wXBqNoGPHQQxya2rV%2B1QMw@mail.gmail.com> <A8AE31ED-CD22-4FE1-B888-3371502B634E@me.com> <CAJ-VmonZvFc24NcOdSK8SbpDa8Zt3xjA%2BbLQ6QnKH%2Bc-JmAmpw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Aug 9, 2015, at 11:03 PM, Adrian Chadd <adrian.chadd@gmail.com> = wrote: >=20 > poke dim and the other compiler-y people. They have a plan, and it's > about time we started the deorbit. :) Well seriously though, let=E2=80=99s also take this opportunity to clean = things up with the build process and maybe also some of the release bits = too, since they=E2=80=99re fairly intrinsically tied together. I tried doing a =E2=80=9Cmake release=E2=80=9D in /usr/src today, = harkening back to the days when I was Release Engineer for FreeBSD and = that single command was all one needed to get a .iso image and some boot = floppy / QIC tape suitable media (!) for the i386. Obviously there are = more release products now, from single disc ISOs to DVDs to USB boot = device installers, and I quickly saw that all of these various targets = had moved into /usr/src/release (OK, that seems reasonable) but even = then, and after reading /usr/src/release/Makefile, I could not get = =E2=80=9Cmake cdrom=E2=80=9D to work. Looking at = https://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/release-build.= html references a script that doesn=E2=80=99t even exist anymore, so the = docs are clearly out of date. My point, and I do have one, is that while we=E2=80=99re cleaning things = up, and I think we should, there should be some clear goals to what = we=E2=80=99re doing: 1. The =E2=80=9Cbuildworld, buildkernel and release=E2=80=9D targets = should DTRT with a known and documented set of target switches like = TARGET_ARCH and whatever else is deemed =E2=80=9Cminimally necessary=E2=80= =9D to cross-build, or self-host for that matter, on any given platform. = Where self-hosting is the scenario, the defaults should also be set = reasonably enough to make those build targets Just Work with a minimum = [absence] of superfluous decorative flags or variables. In short, the Principle Of Least Astonishment is an excellent guiding = principle to follow and the minute someone says =E2=80=9Cwell, it=E2=80=99= s totally obvious how to build for the beagleboner 9000, you just go to = http://www.4chan.org/os-stuff/giggle/he-said-boner/davesdocs/howtomakefree= bsd.html and follow the instructions there after also customizing the = first 30 lines of the whiffle.sh script=E2=80=9D, we should be allowed = to kill them and eat their liver with some fava beans and a nice = chianti. Then we should automate it and document it on our own web = site. 2. We need to define what the targeted architectures are for =E2=80=9Croun= d one=E2=80=9D of this because reading = https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/arch= s.html is only partially enlightening. According to that, only i386 and = amd64 are tier 1 and tier 2 are ARM, pc98 (really??), powerpc and = sparc64. In Tier 3, in a lonely classification all by itself, is mips. = Even if we adopt all of them, which of those require an external = toolchain and which will build with the current clang? If you read = papers like = http://llvm.org/devmtg/2014-04/PDFs/LightningTalks/2014-3-31_ClangTargetSu= pport_LighteningTalk.pdf you could easily develop the impression that = even its own developers aren=E2=80=99t so sure, but I=E2=80=99m guessing = we have a bit better of an idea than that, no? 3. We need to collect all of the cross-building voodoo in one place and = then set about encoding it into the Makefiles such that even a = reasonably intelligent golden retriever can build one or all of the = supported target architectures. For extra credit, they should also be = able to pop out an installation image for it since the Release Engineer = often has better things to do than build custom images for folks, but = that=E2=80=99s also the only way to really TEST anything so =E2=80=9Cself = service=E2=80=9D should definitely be possible and even sort of fun. 4. We need to de-orbit gcc as previously discussed since nobody can = claim that this is regressive motion if there is a plan for the 88000 = and i860 ports and they even work better than they did before. I have a lab (several actually). I have engineers. How can we help. - Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D6FF7F3C-DF1E-4D60-99DB-BCE162A27126>