On Wed, 6 Feb 2002, Andrew Brown wrote:

# ># For host tools, the objdir also reflects the host architecture.
# >
# >1.  This isn't just for host tools -- it's for other things inside the
# >source tree (i.e.  /usr/games/boggle, where the dictionary thing blew up,
# >which led me to discover the misnamed obj.* dir).
#
# the boggle thing actually involves host tools, since it needs to do
# work targeted at the target machine, not the host machine.

That makes *no* sense to me, could you try that again?

# >2.  Even if it were for host tools, wouldn't that also cause problems
# >with building for multiple architectures at the same time?
#
# you have paths like this, i presume?
#
# tools/obj.algor/tools.NetBSD-1.5ZA-i386
# tools/obj.alpha/tools.NetBSD-1.5ZA-i386
# ...
#
# which is
#
# tools/obj.${MACHINE}/tools.${_HOST_OSNAME}-${_HOST_OSREL}-${_HOST_ARCH}

Yeah, I got that.

# so that the obj.foo bit will change depending on your target, but the
# tools.bar piece will change depending on where you're building.  you
# can, thus, use the same source tree on 17 different (host) ${MACHINE}s
# to cross-compile to each one of the aforementioned 17 ${MACHINES}s,
# and end up with 169 non-conflicting tool directories.

Right.  Except that obj.foo got named for the i386 where I'm doing the
build, not for the sparc that I'm building for.

I'm not sure I follow why this is.  Is boggle an anomaly?

Oh, and also:

.{OBJDIR}/foo:

targets do not work!  Make does not expand them in time.

# >Either way, I posit it is a bug.  Shall I submit it as such?
#
# i'd say no.  it kinda irks me that each time my (host) netbsd kernel
# version gets bumped, i need to build new tools, but i can deal with
# that.

Noted, thank you for the sanity check.

				--*greywolf;
--
NetBSD: making all computer hardware a commodity.