From owner-freebsd-current Mon Jan 29 14:59:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA18444 for current-outgoing; Mon, 29 Jan 1996 14:59:40 -0800 (PST) Received: from werple.net.au (werple.mira.net.au [203.9.190.18]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA18426 for ; Mon, 29 Jan 1996 14:59:32 -0800 (PST) Received: from cimaxp1.UUCP (Ucimlogi@localhost) by werple.net.au (8.7/8.7.1) with UUCP id JAA06436 for mira!FreeBSD.ORG!current; Tue, 30 Jan 1996 09:52:40 +1100 (EST) Message-Id: <199601292252.JAA06436@werple.net.au> X-Authentication-Warning: werple.net.au: Ucimlogi set sender to cimaxp1!jb using -f Received: by cimaxp1.cimlogic.com.au; (5.65/1.1.8.2/10Sep95-0953AM) id AA14234; Tue, 30 Jan 1996 09:51:37 +1100 From: John Birrell Subject: Re: I'm rather annoyed with -current. To: sri.MT.net!nate@werple.net.au (Nate Williams) Date: Tue, 30 Jan 1996 09:51:31 +1100 (EST) Cc: time.cdrom.com!jkh@werple.net.au, FreeBSD.ORG!current@werple.net.au In-Reply-To: <199601291556.IAA08024@rocky.sri.MT.net> from "Nate Williams" at Jan 29, 96 08:56:51 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-current@FreeBSD.ORG Precedence: bulk > Both of these problems are due to ordering problems in the Makefile, > which can be fixed in the 'world' target, but don't really fit into the > current model used. I agree with this. The changes are not bugs in the -current code committed. Instead they show up a bogus build process. > > You need to build and install rpcgen *before* the include files are > built. There is also a dependency problem with either the libraries or > the crt0.o file (I don't remember which one is first.) crt0 and libc will build OK with installed tools, but they *must* be installed _together_. If you check the logic in /usr/src/Makefile you will see that, on the surface, they *should* be built and installed together because they are not part of separate targets. The fact that they are not must be the result of 'make depend'. Sigh. > > It basically boils down to the fact that we *should* be building the > sources out of the src tree and not out of the stuff in > /usr/{lib|include} etc... (Which I've argued against in the past as > un-necessary and complex, but I think we've now reached critical mass > and require it.) It is not simply a matter of using -nostdinc, -nostdlib and -nostartfiles although these are still needed. There are too many race conditions in the software design. Look at the build process and you will see that it only works at all because it tries to install *all* header files up front regardless of what their dependencies are. Normally this is OK, but in the rpcgen case it is not (though no fault of the rpcgen code). [Stands up on soap box to begin preaching... I've been flamed by NetBSD folk for saying what I'm about to, but I'll say it anyway. 8-)] In the *BSD software design there is no concept of header files that are private to the kernel/driver build and header files that are purely for user-land code. There is also no modularity within the design - everything depends on everything. As a result of this design, the build process has to take all the sys header files and install them for the user-land code to compile against. And because they are all available, people expect to write code that *requires* their use. Including the build tools... so the dependencies become horribly complex. And race conditions arise. At any time, the installed /usr/include /usr/bin /usr/lib etc *should* be capable of starting a 'make universe' (since the world is imperfect) and there should be a concept of 'release' to update /usr/include /usr/bin /usr/lib _only_ when the 'make universe' has been successful in creating a complete set of compatible files to install in the traditional places. If I had my way [And of course I think the world is imperfect because I haven't had my way yet 8-).] the basic set of header files that user-land programs compile against would not contain any implementation specific stuff and in particular no device driver or kernel specific stuff. If you want a list of these header files, take a look at POSIX 1003.1b-1993 Annex C. That's a start. These don't include any networking stuff - the basic build tools should not require it. Note that these header files do not contain enough definitions for things like executable file format etc. Programs like ld need extra header files, but there additional header files should not be visible to the build process until the point where they are required. These header files should *only* be installed _with_ the program (or library) that they are compatible with. And the rest of the build process should work the same way. By _preventing_ the build process from being able to access a file (include, library, program) until all its dependencies have been processed, race conditions are avoided - you just can't build the software without getting the design right. The build order of libraries and programs should NOT be allowed to change depending on the poor software design and coding in C source. [This is what is happening at the moment - make depend can't handle race conditions so it gets the build order wrong - someone forgot to teach it that there *is* no correct order]. The order that directories are processed should be *designed* into the makefiles. This is the way that it looks when you read the current makefiles. But when you see the way it works... If you're not ready to flame me yet, take this: FreeBSD should STOP USING MAKE DEPEND. You need to ensure that at *least* the order that directories are built does not change because of something like make depend. The build process should not have a separate command to work out dependencies. These should be determined on-the-run by make so that you can't build the system without the dependencies from being checked. Two years ago we bit the bullet and stopped using make for these reasons (and many more like version control, traceablility, automated software testing before release). So I know that what I am saying can be done! Regards, -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au 119 Cecil Street Ph +61 3 9690 6900 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137