Date: Tue, 30 Jan 1996 09:51:31 +1100 (EST) From: John Birrell <cimaxp1!jb@werple.net.au> To: sri.MT.net!nate@werple.net.au (Nate Williams) Cc: time.cdrom.com!jkh@werple.net.au, FreeBSD.ORG!current@werple.net.au Subject: Re: I'm rather annoyed with -current. Message-ID: <199601292252.JAA06436@werple.net.au> In-Reply-To: <199601291556.IAA08024@rocky.sri.MT.net> from "Nate Williams" at Jan 29, 96 08:56:51 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601292252.JAA06436>