On 24-Sep-08, at 3:14 AM, Alan Barrett wrote:
On Wed, 24 Sep 2008, Mikko Rapeli wrote:I like it when I can just try'MKSHARE=no MKBFD=no CPUFLAGS=-mthumb-interwork' ./build.sh ...' quicklyWould 'build.sh -V MKSHARE=no -V MKBFD=no -V CPUFLAGS=-mthumb- interwork ...'be more difficult for you? More generally, for everybody: Would it be good or bad if build.sh cleared the environment, so that the only way to set variables that influence the build was through "-V variable=value" flags passed to build.sh, or through mk.conf?
I think that would be a step in the right direction.The only issue that may affect some people might be the default PATH to use for the host tools. I found it sufficient to set it to /bin:/ usr/bin (just as one would hope) for builds hosted on NetBSD.
The other two variables I found I had to re-add to the environment, as I hinted by posting the top of my wrapper script, were USER and SHELL, though it may be they were only really needed within my wrapper script itself (USER is certainly used in my wrapper -- and some of my script usage needed /bin/ksh).
Would it be good or bad if the default mk.conf file was ignored by build.sh, and if you had to specify "-V MKCONF=/path/to/mk.conf" if your really wanted to use a mk.conf file?
That wouldn't matter too much to me because my wrapper script already does that for me, but I think the sane default would be to use the mk.conf file that's in the same source tree which is being built and those who wish to use some other, perhaps shared, mk.conf file could then use -V. I think it's rather insane to use /etc/mk.conf as the default, even on NetBSD hosted builds.
--
Greg A. Woods; Planix, Inc.
<woods%planix.ca@localhost>
Attachment:
PGP.sig
Description: This is a digitally signed message part