Date:        06 Feb 2003 17:00:39 -0500
    From:        "Perry E. Metzger" <perry@piermont.com>
    Message-ID:  <87wukd2ho8.fsf@snark.piermont.com>

  | I agree that wrapper scripts are more powerful. I disagree that they
  | are always more convenient. Some people find them more convenient,
  | some do not. I think things work best when everyone gets to have
  | things set up in a way they found comfortable. You prefer wrappers, I
  | prefer not to have to use them. "Chacun a son gout."

I know this issue has been pretty much written off in the past few days,
but Perry, if you're using build.sh you are using a wrapper script, that's
what it is (a wrapper around make).

Why you'd have objections to using another wrapper, when you're willing to
use one, I have no idea.

Your other objection was that a wrapper script requires everyone to write
their own?   Why?   You (or someone) can always create one and share it
with others - if there's one that lots of people seem to like, I assume it
could get added to the distribution (or added to pkgsrc).

I agree with most others, no special config files (shell script fragments)
to be included - the only thing I'd really like to see (I mean, would be
prepared to tolerate, not want) would be an option that allowed another
file to be sourced if given.   But if you have that, you're probably going
to want a wrapper to avoid typing it every time, and if you're going to
build both the wrapper, and the config file to pass to build.sh, and the
config file is just going to set vars, you really could just have the
wrapper set the vars, export them, and then forget the config file)

For what it is worth, and in case you want to make use of it, the guts
of (an older version of) my wrapper script is ...

cd /usr/src || exit 4
env -i \
        PATH=/sbin:/bin:/usr/sbin:/usr/bin \
                "USER=$USER" \
                "LOGNAME=$LOGNAME" \
		MAKECONF=/dev/null \
        /bin/sh build.sh "$@" \
                -D "${TARGET}" -d -O /usr/obj -R "$SNAP" -T /usr/obj/tools -u

That's obviously, for the previous build.sh syntax, I don't have my newer
version with me at the minute; as I recall the changes were just to get rid
of the -d and add "release" down the end (I always "make release", so if it
succeeds I have what is needed to write a CD, so if I install it, I always
have that version available).

The rest of the script deals with setting the vars to appropriate values,
redirecting output to a suitable log file, making sure the right file
systems are mounted, directories created, etc,  then when the build finishes
(successfully), making the src set tarballs, and compiling both versions
of X (done running chroot to the newly created $TARGET, so all the new
libraries, tools, etc get used - and yes, this does mean that a suitable
kernel needs to be running already), and including both of those
in the snapshot directory, making sure that tailored kernels for all the
systems I need them for are built, etc.

I'm not currently doing cross-builds (or the X building stuff would fail,
clearly).

kre