[ On Saturday, June 26, 2004 at 10:45:04 (-0500), Frederick Bruckman wrote: ]
> Subject: misc/26072: Request: an option to build.sh, to build kernels without running "config" and "make depend"
>
> 	Impatient kernel hackers would like to be able to build kernels using
> 	build.sh without running "config" and "make depend". The "make depend"
> 	part takes an especially long time, and it often happens that you've
> 	changed one source file in a way that you know that "make depend" isn't
> 	needed.

Hmmm...  maybe "build.sh" isn't the best venue for this.  Below are some
changes adding a new "custom-kern" target I added to src/Makefile and
src/etc/Makefile.  These have served me very well.

These are against the netbsd-1-6 branch, and line numbers are way off,
but they should give you an idea of what I mean:

Index: Makefile
===================================================================
RCS file: /cvs/master/m-NetBSD/main/src/Makefile,v
retrieving revision 1.175.2.3
diff -u -r1.175.2.3 Makefile
--- Makefile	30 Nov 2002 15:27:33 -0000	1.175.2.3
+++ Makefile	1 Nov 2003 22:13:22 -0000
@@ -219,6 +223,21 @@
 # XXX this needs to change when distrib Makefiles are recursion compliant
 dependall-distrib depend-distrib all-distrib:
 	@true
+# make CUSTOMKERN=CONFIG [UPDATE=yes] [NODEPEND=yes]
+#
+.PHONY: custom-kern
+custom-kern: .MAKE
+	(cd ${.CURDIR}/etc && ${MAKE} $@)


Index: etc/Makefile
===================================================================
RCS file: /cvs/master/m-NetBSD/main/src/etc/Makefile,v
retrieving revision 1.219.2.4
diff -u -r1.219.2.4 Makefile
--- etc/Makefile	24 Nov 2002 15:47:37 -0000	1.219.2.4
+++ etc/Makefile	21 Jun 2004 21:19:07 -0000
@@ -378,5 +392,25 @@
 
 snap_md_post: check_DESTDIR check_RELEASEDIR
 # nothing here -- look in the machine-dependent Makefile.inc
+
+.PHONY: custom-kern
+custom-kern:
+.for configfile in ${CUSTOMKERN}
+	@[ ! -d ${KERNOBJDIR} ] && mkdir -p ${KERNOBJDIR} || true
+	cd ${KERNCONFDIR} && ${CONFIG} -b ${KERNOBJDIR}/${configfile:C/.*\///} -s ${KERNSRCDIR} ${configfile}
+. if !defined(UPDATE)
+	cd ${KERNOBJDIR}/${configfile:C/.*\///} && ${MAKE} distclean
+. endif
+. if defined(NODEPEND)
+	cd ${KERNOBJDIR}/${configfile:C/.*\///} && ${MAKE}
+. else
+	cd ${KERNOBJDIR}/${configfile:C/.*\///} && ${MAKE} depend && ${MAKE}
+. endif
+	@echo ""
+	@what ${KERNOBJDIR}/${configfile:C/.*\///}/netbsd
+	@echo ""
+	@echo "get your new '${configfile}' kernel from:"
+	@echo "	${KERNOBJDIR}/${configfile:C/.*\///}/netbsd"
+	@echo ""
+.endfor
 
 .include <bsd.prog.mk>


>        It is always possible, of course, to build kernels directly in
> 	the build directory using the correct "nbmake-<MACHINE>", but it's
> 	inconvenient to type the tediously long path.

Well I'd argue that's also a slightly different problem too.  I solve
this prolem with a small set of helper functions and aliases and
environment variable settings that I source into my command shell.

E.g. I would do the following in a new shell window to update a custom
test kernel after making a quick change to one or a few source files
where only those files needed re-compiling:

	$ cd /usr/src
	$ . ./myhelpers.ksh
	$ seti386tools
	$ nbmake-i386 custom-kern CUSTOMKERN=MYKERN UPDATE=yes NODEPEND=yes

That last one could be shortened a lot more with either more specific
makefile targets and/or additional command aliases, but normally I don't
do it often enough in a fresh window (i.e. one with no shell history)
that I find it too tedious to type.

Note that one can be a bit more objective when deciding whether to use a
makefile target or a script/alias/shell-function by considering the
namespace issues.  Makefile targets are a convenient way of
encapsulating shell functions in such a way that they are very easily
accessed but are in a separate namespace from other commands.  Makefile
targets also get very easy access to makefile macros (e.g. mk.conf
settings) too, but on the other hand you can't set $PATH or create
command aliases for the invoking shell from within a Makefile.

The "seti386tools" alias sets up the right $PATH with the right
$TOOLDIR:

	$ alias setalphatools
	setalphatools='setNOtools ; export TOOLDIR=${MY_alpha_TOOLDIR} ; dirprepend PATH ${TOOLDIR}/bin'
	$ setalphatools                                                                                         
	$ type nbmake-alpha
	nbmake-alpha is a tracked alias for /build/woods/building/NetBSD-1.6.x-alpha-alpha-tools/bin/nbmake-alpha
	$ alias nbmakealpha
	nbmakealpha='${MY_alpha_TOOLDIR}/bin/nbmake-alpha'

("building" is $(hostname) in this example)

I can post (and/or attach to this PR) the full "myHelpers.ksh" file if
anyone would like it.  It's got other goodies such as aliases like
'cdi386obj' (uses the ksh "cd old new" trick) which allows me to jump to
the relative object directory without having to pollute my source tree
with objdir symlinks.  It's not perfect, but in combination with my own
build.sh wrapper I can build with source from pretty much anywhere and
with products going to pretty much anywhere else, within certain naming
conventions.

alias cdalphaobj="cd / ${BUILD_HOME}/NetBSD-1.6.x-${HOST_MACHINE}-alpha-obj/"

(which assumes various symlinks have been created in the objdir tree
too, and they are by my build.sh wrapper...)

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>