>But what "configuration" are you changing, and does that result in >changes to the tree, or are you passing a different mk.conf, or >something else? One of the targets (the 486) needs a customized mk.conf to either enable -Os optimization in userland, or alternatively, tell ./build.sh to use PCC (which is only documented in share/mk/). I'm under the impression mk.conf is best practice to place all environment variables besides MAKECONF. The build tree is the same as the one that I'm using for my CD driver, but this doesn't affect any generic kernel builds for x86 (i386 or amd64) as of right now (although that might change).
>See pkgsrc/sysutils/etcmanage for the scripts I use, which are aimed >at having a source tree per branch and organizing tool/obj/release/dest >directories in a way I like. Will do, thanks for the info. >If you want to pass different mk.conf files and have different paths, >that should be pretty easy. The basic hint is to not insist on passing >one argument, and accept that you will set multiple options. That's fine. I just wanted to make sure this was the "best practice", so I don't run into cross-arch or cross-mk.conf errors later on. The only way I've seen to set different mk.confs is to set the variable on the command line either prior to (and export) or when invoking ./build.sh. Is this correct, or is there an undocumented option to set it on the command line? >./build.sh -m i386 -j8 -x -u -U -O /usr/obj/gdt-current/i386 -T >/usr/obj/gdt-current/tools -D /usr/obj/gdt-current/destdir/i386 -R >/usr/obj/gdt->current/>releasedir -X /u0/n0/gdt/NetBSD-current/xsrc release Do you set the kernel in mk.conf, or is this just an example where you skip building the kernel/it's already built?
