Date: Tue, 24 Jun 2014 10:43:47 -0400 From: Glen Barber <gjb@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-current Current <freebsd-current@freebsd.org> Subject: Re: Problems building FreeBSD 9.2 on FreeBSD 10 Message-ID: <20140624144347.GA48694@hub.FreeBSD.org> In-Reply-To: <3DC0E4E6-A4B5-43EE-BD21-38B68DAE42F1@bsdimp.com> References: <CAG=rPVd5XGz8hfuBtcOuuZp8ND1ssWoTkVNn0Hg6Li_2-NrgcA@mail.gmail.com> <1ED3AC7E-0F74-46A7-BAAA-E30600DC23BB@bsdimp.com> <CAG=rPVeP32=y3VZgn0MXFPrr8tevL=jOsCow=rvpxRevmvoLqA@mail.gmail.com> <8CD24B0A-DF45-4437-BEBE-8C67B241DE93@bsdimp.com> <CAG=rPVcrJpP_1VcKZnsxAugBywJBXg63p2piX7nPndTunPEWDQ@mail.gmail.com> <2063888D-CCAE-431B-A409-F17AA4422006@bsdimp.com> <20140624011251.GN1218@hub.FreeBSD.org> <60320DD3-56C4-4922-A537-FF94C392A45A@bsdimp.com> <20140624022410.GP1218@hub.FreeBSD.org> <3DC0E4E6-A4B5-43EE-BD21-38B68DAE42F1@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--/04w6evG8XlLl3ft Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Trimmed CC a bit. On Mon, Jun 23, 2014 at 11:42:20PM -0600, Warner Losh wrote: > On Jun 23, 2014, at 8:24 PM, Glen Barber <gjb@freebsd.org> wrote: > > I sort of typed what I meant a bit backwards from what I intended to > > write. What I meant (sort of) is, "I would like to discuss our forward > > thinking on backward-compatibility." > >=20 > > I fully understand forward-compatibility is not feasible. >=20 > We already build current back to the stable/8 branch. 7.x is no longer fe= asible, supported or tested. stable/10 is the only one that is required, bu= t enough people use stable/9 machines it will work. stable/8 has one custom= er that is keeping it going, so I suspect it will stop working in the comin= g years, maybe before 11 is branched. >=20 To be clear, I am talking about the other direction. Meaning, being able to "reliably" build N-2 from head/, without needing to do silliness like 'make make buildworld', or "not using -jN." > > I hate to even suggest this, but the ports tree (ab)uses the notion of > > using the kern.osreldate for certain things. This, however, requires > > proper bumping of __FreeBSD_version when needed, and maintenance of the > > Makefiles for the kern.osreldate-specific things. >=20 > We already do that. It mostly works most of the time, so long as the delt= a isn=E2=80=99t too great, and we don=E2=80=99t have high compiler/tools/ma= ke velocity=E2=80=A6 Except we don=E2=80=99t use the kernel version, but ra= ther the installed tools version as indicated by a .h file. That=E2=80=99s = more robust. >=20 True. Thank you for the sanity check. > > The benefit to this is that it would help prevent pissing off ports > > developers and make their lives a bit easier when userland / kernel > > things change. It would, however, (expectedly) is that it would force > > src committers to do the right thing. Win-win, IMHO. >=20 > What should we do we aren=E2=80=99t doing today? >=20 There have been a number of times where changes that should deem a __FreeBSD_version bump necessary either 1) do not bump __FreeBSD_version at all, or 2) bump __FreeBSD_version several days (or longer) later. So, we're left with a window of time where something is "different enough", but there is no corresponding version change to reference. This is somewhat tangential to my original annoyance here though. :) > > Personally, and no I won't discuss more on this, I'm in the camp of "I > > don't really see clang as a feature." It caused our ports developers > > and maintainers a mountain of headache to convert to the "invisibly new > > great thing", it increases our overall buildworld by a non-insignificant > > amount of time, and it has personally caused me headaches (still > > ongoing) trying to figure out what the correct incantation of evil to > > wish over the cauldron to get BeagleBone images to build. (They're > > failing because gcc is not being installed on both head/ and stable/10/, > > and despite the game of "musical KNOBS" I've been playing over the past > > few days, I'm running out of hair to pull out of my head.) >=20 > Yea, if you are using crochet, that=E2=80=99s because crochet uses xdev r= ather than a ports compiler (which in all fairness didn=E2=80=99t exist whe= n it started) to build u-boot, which basically requires gcc. >=20 > The compiler rework in head is still a work in progress. What=E2=80=99s t= here now is better than before, but still isn=E2=80=99t quite right. I do p= lan on fixing that before summer is out. >=20 It isn't just head that is a problem with crochet, though. stable/10 has been a problem since, as far as I can tell, roughly early May. > >> But 9.2 will never build on head because it is broken with bmake, whic= h is now standard for head. Since 9.2 cannot be changed, and since we=E2=80= =99ve removed (or nearly) fmake in current, chances are quite good it will = never build on head again without some special handling. > >>=20 > >> In summary, good luck! there=E2=80=99s a lot of use cases here, and it= will take time and effort of multiple people over the long haul to keep it= working. Best effort may be larger than you estimate=E2=80=A6 I won=E2=80= =99t stand in your way, but I=E2=80=99m afraid my time available to help is= limited. > >>=20 > >=20 > > As Ozzy once sang: > >=20 > > "I'm just a dreamer > > I dream my life away > > I'm just a dreamer > > Who dreams of better days=E2=80=9D >=20 > Since I was commenting on the opposite problem of what you were wanting c= omments on, my harshness is justified. >=20 My comment wasn't a comment on your comment. :-) > What you want though, we largely already do, though maybe with a few more= warts than necessary (which we should try to fix). Most of the warts are d= ue to gcc/clang division being done badly and unsustainable initially and t= he cleanup taking a bit of time, not specific version issues. >=20 > Back to your basic point, the issue becomes a testability one: not all co= mmitters can reasonable be expected to have 8 or 9 systems to test every ch= ange. Having a 10.x system to test changes is a bit of a stretch as it is, = but it is the official policy that many folks play fast and loose with the = rules because they haven=E2=80=99t been burned too often by it=E2=80=A6 VMs= , Jails, etc of various flavors can help, but some info does leak through (= mostly the info leaks are bugs or kludges that well meaning people shouldn= =E2=80=99t have done given the historical knowledge we have about the ill e= ffects of certain ways to do conditional compilation). >=20 To be fair, we do have reference machines in the cluster running head/, stable/10, and stable/9. Glen --/04w6evG8XlLl3ft Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJTqY6jAAoJELls3eqvi17QZIkP/1ZQ6eF3s6KOFoDXSW6IUKtz 52yhjjWMjPddLacpoquiUdYJBGsoFWe+8TFk/l5Unyh1wHnnBb1ag4ub4R6ht0lF EhqZ/U9d7hLNDDzFC47nG2ew6P00sczeC+FxaFhL16i/ZrpKGo3pmJF6mIcuOkni N2WCVrKEAdh9+R4zdA2jEzpCulmJiD/5TUa2FQzhBNm4jAYxPRcXXEUKdHRewmT/ NrzhI0Bdy3QUNNPVBmhd6wkAilQcA0LlPzrpRz0h4LX3nXlS9mthQjodwCXAT7uG o/H+7N2/26X4vnZYBLJkFz0LeJ03BS95THKOY4ikkeEFT3Rth86QOADSm5NnFBP8 VgDpaPc+BhisKgQ4uIyk3sZN8uopk55uN/AIe3g7wX7U0KSDxOwFy3SqStobQFeU GiLPWAZaDTe1HHhp+NQoX2NKoZC20pI4YTy/u38ORJrIOUU7PhcP6ydm3BgFTOyb wWtaFiU4KDeRx6sb6JjVtE/45U6idzd/bn3afUEmUrddfS0PuwBfrJyMuZdQHsfo UaqIE9s9vhcQqG7dQoOvFdNI8AGEs2So8GyvyBqn3J9911rOXe+0jxar5MdTao4W KXFXBevSfuIkC8K1tP6biWVY/jU6SpLT4iO5T3o3xGOIpDZe5mHbrSq5vuc/Hstm 956AgTln6ZkS0EXg5bXe =87kE -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140624144347.GA48694>