Multiple NetBSD targets using the same OBJDIR

[thor0505%comcast.net@localhost]

Hello all, 
 
I have a need to build NetBSD for multiple architectures using the same source 
tree. While I understand that one can use the same tools directory for all 
possible targets, I have not found an option to separate objects, releasedir, 
and destdir according to the target or some chosen ID (I also have the need to 
build NetBSD for the same architecture in two different configurations). 
According to build.sh documentation, destdir and releasedir are only set based 
on the target arch when left to their defaults which are placed inside OBJDIR, 
and cant otherwise be set on a target-basis with build.sh alone. I understand I 
can emulated the behavior by wrapping build.sh in another shell script. I can 
then define platform-specific environment variables which are passed into 
build.sh path options. However, I was wondering if there is a more canonical 
way built into ./build.sh to accomplish my needs? 
 
According to BUILDING in the source tree, the environment variable Im looking 
for is called BUILDID, which is a BSD make variable. However, beyond this 
reference, I am unable to find other information on using BUILDID. Provided 
that I set this variable on a target basis, will this permit me to have 
multiple target configurations built in the same OBJDIR? Or is BUILDID not 
sufficient to guarantee that the object files from a build in one configuration 
(different arch and MAKECONF, for instance) will overwrite the object files in 
a previous configuration. 
 
The other possible canonical solution Ive seen, according to the following 2003 
mailing list post: 
http://thread.gmane.org/gmane.os.netbsd.current/10183/focus=10219 is to use the 
M option to build.sh. However, I would like to keep the number of extra 
directories/disk space created at a minimum, as the M option appears to 
recreate the entire source tree as well as object directories. The option also 
appears to be limited to objdir and not releasedir and destdir.
 
Perhaps wrapping build.sh in another shell script is still the most viable 
solution?
 
Thanks for any help any of you can give me!
 
-- 
William D. Jones 
Rowan University | ECE | 2012 
Member IEEE 
Member Tau Beta Pi 
thor0505%comcast.net@localhost 
Message sent using 'Windows Live Mail' client.