[ On Thu, April 30, 1998 at 12:59:43 (-0400), Todd Vierling wrote: ]
> Subject: Re: kern/5377: sys/system.h inludes lib/libkern/libkern.h for LKM too
>
> Though the whole tree is not yet cross-compilable (and I'm setting up two
> cross environments for the explicit purpose of putting a finessed system in
> place for that), the tree can be compiled on the same architecture for
> several different releases:  $DESTDIR does that for you.  As of 1.3, the
> `gcc' frontend program was fixed to make this work properly (there was a
> bug wrt the -nostdlib option).

Things like $DESTDIR are not exactly what I had in mind.

I'm more interested in the use of a relative path for -I similarly to
the way the kernel builds.

This is especially important for stuff that makes use of kernel
information (including everything that calls ioctl()), but it should be
possible for all subsystems that refer to header files of other
dependents, such as libraries, where those header files are normally
stored in the source subdirectory of the dependent subsystem.

Once upon a time, a long long time ago, I tried advocating that all
shared header files be moved into /usr/src/include for this reason, but
doing that would cause a lot of difficulty and upheaval.

I agree that $DESTDIR is somewhat of an elegant solution.  However it
has the wrong connotations and implies that a complete source tree needs
to be present and that a full build process needs to be done.

I think several tricks need to be accomplished.  One is the question of
selecting either the host's toolchain, or building and using a version
of the toolchain unique to the current source tree but hosted by the
currently running OS.  I think this latter option can also instantly
solve the problem of having a separate toolchain for cross-compile
builds.

I have two somewhat related goals in mind though that are separate from
being able to do cross-compilation, but in the end have the same
effective result.

The first is that I want to be able to work on small parts of the source
tree without having to rebuild the world and re-install everything.
This is especially important for changes that have to be co-ordinated
between kernel and user-land (eg. the classic of 'ps' and friends).  The
idea is to be able to build just kernels and the related user-land
tools, install them on a test machine, and test away.  It should be
possible to do this kind of experimentation without having root access
to the build environment (including building the toolchain and/or
libraries if necessary), and without having to compile anything on the
target test machine.  Indeed it should be possible for the target test
machine to be an entirely different architecture or even a different OS
base.

The other thing I want to be able to do is to build complete multiple
different releases on a server machine.  I.e. right from 'cvs co' or
whatever through to having the final install sets, floppy images, and
whatever.  This includes where the target build may be so radically
different as to have a totally different system call interface, etc.

In both cases it should be immediately obvious that the build
environment should not need to be even running the same base OS as the
target environment, never mind the same architecture.  The only
requirement should be source code compatability for the build
toolchain.

In both cases it should be possible to avoid building the toolchain
twice if the build host's environment is sufficiently compatible.

I do this kind of work every day with applications, and have in the past
done this kind of stuff in developing embedded systems.  Indeed the
entirety of NetBSD is smaller than some applications or embedded systems
that I'm aware of.

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>