> This doesn't help cross-compiles.  A better solution is to have a
> generic userland tool to build filesystem images so that there are
> no kernel dependancies at all.  This is part of the "There's work
> in progress..." bit that Luke mentioned.

We've developed a set of scripts for non-root cross-builds which use generic
tools.  They're to the point that we use them daily for generating nfs-root
mountable file systems for cross-development.

We're interested in people's thoughts on our approach, so I'll outline it
here.

Our design criteria were:

  1.  The user running the build is trusted -- he knows the root password on
  the build machine.  The reason for the non-root build is not so much
  security as convenience and disaster-avoidance.

  2.  Changes to the existing build system should be minimized.

  3.  The source and object directories should be owned by the normal user.

  4.  The files in DESTDIR should have all of the proper ownerships and
  privileges.  The resulting directory should be directly NFS-root
  mountable.

  5.  Building for multiple targets from the same source directory should be
  straightforward.

With our system, one can simply go into a directory in the source tree and
do, for example,

	xmake -M <machine> all install

or
	MACHINE=<machine> xmake all install

or in certain circumstances simply

	xmake all install

and the result will be a non-root make and a privileged install to the
<machine>'s DESTDIR.  However, since only the DESTDIR manipulations are run
with root privileges, the source and object directories are all owned by
normal user, which we find far easier to work with.

The actual mechanism we use is:

  1.  A script `/usr/pkg/cross/bin/xmake' expects either an argument `-M
  <machine>' or an environment variable `MACHINE=<machine>' to determine the
  cross-target name.

  This parameter also chooses among configuration files with names
  /usr/pkg/cross/libexec/xmake/<machine>.xmk.  These configuration files
  perform part of the function of /etc/mk.conf.

  2.  The `xmake' script puts /usr/pkg/cross/libexec/xmake at the head of
  the user's execution PATH.

  This directory holds about a dozen small scripts which intercept
  invocations of the programs required to install the system.  (These
  scripts currently include chgrp, chmod, chown, config, cpio, install,
  install-info, ln, makewhatis, mknod, mtree, mv, pax, rm, and zic.)

  As an example, the `install' script contains:

	sudo-if-destdir /usr/bin/install "$@"

  The `sudo-if-destdir' script also lives in /usr/pkg/cross/libexec/xmake:

	utility=$1 ; shift

	if [ "$(echo $(pwd -P) $* | grep $DESTDIR 2>/dev/null)" ]; then
		sudo $utility "$@"
	else
		$utility "$@"
	fi

  This script captures the name of the utility (/usr/bin/install in this
  example) and runs it under `sudo' if and only if either the current
  directory is DESTDIR or one of the command line arguments refers to
  DESTDIR.

There are a few other details which allow for things like per-project
replacement of etc/mk.conf, and default values for <machine> and DESTDIR,
but they are not crucial to the above mechanism.

Our approach requires only a very small number of changes to the existing
build system.  Most of the changes simply remove absolute paths from
invocations of the above-mentioned utilities so the xmake scripts can
intercept the calls.

Only a single program, the game `phantasia', does not build under our system
because it creates its own installer which wants to write directly to
DESTDIR.  This shouldn't be hard to fix, but we haven't taken the time to do
so.

Does this seem like a reasonable approach?  If so, we could perhaps make a
package of it for inclusion in pkgsrc.

Regards,

David Querbach
Real-Time Systems Inc.