Date: Sat, 26 Sep 2015 13:18:34 -0600 From: Warner Losh <imp@bsdimp.com> To: Bryan Drewery <bdrewery@freebsd.org> Cc: NGie Cooper <yaneurabeya@gmail.com>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r288241 - head/share/mk Message-ID: <CANCZdfoELsVH=a94mCnW7Zb0GAw_%2BmgRHyYVmT9x2dAw5Fo5ZQ@mail.gmail.com> In-Reply-To: <5606A9AE.7070303@FreeBSD.org> References: <201509252303.t8PN3Wx0098623@repo.freebsd.org> <CAGHfRMAJvFuWQSGAMYd3wq0MTXTZuvn6cTzzYhP2rM=9M7caWQ@mail.gmail.com> <5605D4FC.4040205@FreeBSD.org> <CAGHfRMArxy3hQHpWv0ZjZandmafugFhv9%2Bd7Ry2kAg68v%2B1Oaw@mail.gmail.com> <CANCZdfp_bh5Mn%2BbeMzE7ddxWN0RDsxp67SgnoWN-BLiGhtLmRw@mail.gmail.com> <5606A9AE.7070303@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Sep 26, 2015 at 8:20 AM, Bryan Drewery <bdrewery@freebsd.org> wrote: > On 9/26/2015 7:19 AM, Warner Losh wrote: > > > > > > On Fri, Sep 25, 2015 at 11:11 PM, NGie Cooper <yaneurabeya@gmail.com > > <mailto:yaneurabeya@gmail.com>> wrote: > > > > On Fri, Sep 25, 2015 at 4:13 PM, Bryan Drewery <bdrewery@freebsd.org > > <mailto:bdrewery@freebsd.org>> wrote: > > > On 9/25/2015 4:12 PM, NGie Cooper wrote: > > >> On Fri, Sep 25, 2015 at 4:03 PM, Bryan Drewery < > bdrewery@freebsd.org <mailto:bdrewery@freebsd.org>> wrote: > > >>> Author: bdrewery > > >>> Date: Fri Sep 25 23:03:32 2015 > > >>> New Revision: 288241 > > >>> URL: https://svnweb.freebsd.org/changeset/base/288241 > > >>> > > >>> Log: > > >>> Remove 'set -e' that are no longer needed as it is already > default. > > >>> > > >>> When bmake was initially imported at r241298 shell commands > were no longer > > >>> ran with 'set -e' as they were before. This was fixed in > r254980 so they > > >>> again always use 'set -e'. > > >> > > >> The bsd.subdir.mk <http://bsd.subdir.mk>; portion of the change > looks > > like it would cause > > >> issues depending on what's being called (fmake or an earlier > version > > >> of sys.mk <http://sys.mk>; might be used at install time). > > >> > > > > > > We only support bmake in head. And the 'set -e' were only added for > > > bmake compatibility before it was fixed to work like fmake did. > > > > Sorry. Fuzzy memory on the latter item. Yeah, I requested it a > > couple years ago. > > > > We might only support bmake in head, but there's nothing preventing > > someone from doing a source upgrade from one of the older 10 releases > > to 11+. Thinking about this a bit more, this is an extreme edge case > > that doesn't really matter, because people doing source upgrades > > across major releases really should be doing them from the latest > > minor release for the major release > > > > > > I wouldn't state it so glibly. It is not as extreme as you might think. > > For a > > long time compiling -current from a host that was one or two major > > releases old has worked. Currently we advertise that we can upgrade > > from the stable/9 branch point or newer to tip of head (based on values > > in Makefile.inc1). > > > > I don't believe that Bryan's change set changes that in any significant > way, > > but given the large amount of churn he and I (and others) have generated > in > > /usr/share/mk, testing from a 9.x machine would be prudent. I didn't > remove > > some minor bits of code, and also made sys.mk <http://sys.mk>; compatible > > with the FreeBSD 9 > > fmake because of issues like this. > > > > Note that fmake compatibility was explicitly removed around the > META_MODE import time. fmake doesn't work at all currently. > That's only partially true. Some of the compatibility was removed, but not all. We still have (and still want) the compatibility for detecting whether or not to bootstrap bmake or not in src/Makefile. We also added compatibility to sys.mk so that we could build older systems on -current hosts with fmake which uses the system sys.mk for the earliest parts of the build.. So there's still some vestiges of it in the system, and they are conscious decisions to leave them in place. What was removed was building world with fmake for the whole shooting match. Also removed were certain hacks in the other files than sys.mk (and what it includes) to support both. But regardless, we need to make sure that the minimal version we support is actually accurate in Makefile.inc1. And that can only be done by direct testing. I tried to remove it all, but there was much gnashing of teeth and such when I proposed it so I backed away. There's too much need and too many use cases for slivers of fmake support in the tree still. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoELsVH=a94mCnW7Zb0GAw_%2BmgRHyYVmT9x2dAw5Fo5ZQ>