From owner-freebsd-current Tue Apr 4 22:22:45 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA03607 for current-outgoing; Tue, 4 Apr 1995 22:22:45 -0700 Received: from mail.barrnet.net (mail.BARRNET.NET [131.119.246.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA03601 for ; Tue, 4 Apr 1995 22:22:44 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with ESMTP id WAA21353 for ; Tue, 4 Apr 1995 22:19:48 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Wed, 5 Apr 1995 00:21:59 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Apr 1995 00:22:03 -0500 To: "Jordan K. Hubbard" From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: NOTICE: If you care, speak now! Cc: current@FreeBSD.org, rgrimes@gndrsh.aac.dev.com, nate@trout.sri.MT.net Sender: current-owner@FreeBSD.org Precedence: bulk Jordan K. Hubbard writes: >Since it's *never* a good time to do these things, I'll be more flexible: >1. Do what I requested before and bring the entire system up on a public >test box, first. Let us all do a few make worlds and examine it. >2. If it looks really good and doesn't break things significantly, I say >go for it. Thanks for the encouragement. >If you're really serious about this, then before you commit *anything* >you need to bring it up on a machine completely and totally so that >others can run test builds with it and make comments. I'm sorry, but >until I actually *KNOW* and can *SEE* your changes doing everything >they're supposed to do on a real live box then I can't support them >and I doubt that many others will step forward and do so either. I have no problem with your reluctance to "accept" something "sight unseen". I do have a problem with trying to do something with virtually no feedback from the intended "users". If you will read my proposals, I am asking for an agreement that the group will support a change toward the goals that I have stated. If that is achieved, I then ask for acceptance of a specific methodology. I would expect the actual changes to be accepted only after others have adequately reviewed the work. Personally, I see little reason to have more than a very few "targets" at the top level. Make "all", "install", and "distribution" are about all that I see as significant. The important change is that the compiles (for the distribution version, not the "tools" subset) will all be done WITHOUT REFERENCE to the host system. I also want to eliminate the "one user" restrictions and/or the necessity to have a modifiable tree. >If it's just the question of a box to work on. A machine is the least of my problems... I have plenty of compute power and disk space. Remember that one of my "goals" is to avoid messing with the host's environment. At the moment I can accomplish all of this except for the .mk files. >There's no question that we could all benefit significantly from a >cleaner environment, we just have to see it before we're going to >"buy" it! You're otherwise asking us to accept major upheaval >sight-unseen! :-) No, I don't feel that to be the case. As you noted, I've not said much about the details because 1) I was working on those details to make sure that they would work, and 2) I wasn't getting much feedback. This post was intended to either get a commitment to the IDEA and GOALS or prove that I have been wasting my time on something that would never be accepted. You will notice that my proposal is to first gain a consensus and then to intruduce the changes in stages. The way I have worked it out, I can make a few trivial changes that "permit the new syntax" without actually changing anything. Then when the makefiles are ready, a new set of .mk files implements the real changes in the tree structure. Then we go back and clean out all the wasteful parts of the build process. I quote from my previous post: =============== PROPOSED PLAN OF ATTACK For this to happen, I will require the cooperation of ALL comitters. We will need a "standard" for "conforming" Makefiles. Once it is determined, anyone who changes a Makefile would make the alterations to meet the specification. In order to implement this, I propose 1) By Thursday, I will distribute a proposed "standard" for the make files. 2) By Monday, we will agree to the standard. 3) I'll make changes to the .mk files to make them accept both the present Makefiles as well as those that conform to the new standard. 4) Over some period (depending on complexity/manpower) we convert ALL Makefiles to the new standard. 5) I then commit new .mk files which implement the new structure. ================= ---- Richard Wackerbarth rkw@dataplex.net