Date: Thu, 01 May 1997 15:41:11 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Bruce Evans <bde@zeta.org.au> Cc: bde@freebsd.org, current@freebsd.org Subject: Re: -current build is now broken.. Message-ID: <25335.862526471@time.cdrom.com> In-Reply-To: Your message of "Fri, 02 May 1997 07:42:16 %2B1000." <199705012142.HAA27153@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> >> No, it's the responsibility of release/Makefile to be almost independent > >> of the host. Just use -m like I said to get *.mk from the src tree > > > >Technically, yes. In reality, no. If you're keen to change that > >reality then go for it with my full blessings. Otherwise, it's simply > > I just told you how to make it reality for *.mk. Please test and use > the fix and don't blow away my changes without review. Well, as I already told you, I don't have time to do this right now but if you want to wait until the weekend or early next week then I will be happy to look at them for you. In your specific case, however, I think that you can also test the release target just as easily as I can and it's probably time you started doing so anyway since you tend to be in these areas a fair bit. For one thing, doing so would free me from having to fight these sorts of issues with you since you'd be testing the efficacy of any build system changes through the release target as well as the world target, and I think you'd also gain a better understanding of how and where the release system is vulnerable to such changes. The world target is simply an insufficient test if you're going to go modifying the *.mk files (or do any sort of significant Makefile changes, for that matter) as it does not test all the fine permutations of DESTDIR handling and dependency issues. Also, as I said, now that we're *bootstrapping* many 3.0 builds from 2.2 ones there are even more issues involved and, while I'd love to be able to say "chicken and egg, install a 3.0 machine to make 3.0 releases and simplify the makesfiles", I simply don't have the resources to have *both* 2.2 and 3.0 release building machines available at the moment (though it'd sure be nice) nor do, I believe, the other release engineers. That's another one of them-there "real-world constraints" I mentioned earlier. :-) This is also not a question of me blowing away your changes without review, this is a case of you breaking the tree and me fixing it again, pure and simple, and I think I'm entirely justified in saying *please don't do that*. Producing snapshots and trying to serve the developer community through the process of generating releases is already more than difficult enough without making it harder on the release engineers, and I repeat (generally, and to all): If you're going to play with the makefiles or make macro mechanisms then also be willing and able to make a release so that you're sure you haven't broken one of the more subtle dependencies of the system. A make world is *no longer* a sufficient test of such changes and if disk space or other resources do not permit you to run a "make release" then do not make such changes yourself, send them to someone like myself, Poul-Henning or Joerg for review (since all of us frequently build test releases and have the infrastructure for it). This may not have been so critical before, but 3.0 has added a lot of things to the tree and all the contrib reshuffling has created some new frailties that we're going to have to test more thoroughly now. It's either that or people have just had an uncommonly bad run of tree breakage in -current, but I can say that getting a successful release build done in -current has been like winning the lottery lately, and that sucks. More rigorous testing would definitely help. Thanks. Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25335.862526471>