Date: Tue, 7 May 2013 21:25:37 -0600 From: Warner Losh <imp@bsdimp.com> To: "Simon J. Gerraty" <sjg@juniper.net> Cc: Garrett Cooper <yanegomi@gmail.com>, freebsd-toolchain@freebsd.org, "freebsd-arch@FreeBSD.org Arch" <freebsd-arch@freebsd.org> Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree Message-ID: <D6BADC3E-CCC4-4D85-8857-FB6BAAFBB820@bsdimp.com> In-Reply-To: <20130507213118.5277F58097@chaos.jnpr.net> References: <CAGH67wS21otQr1fBqQ2z=XQjUV30QUjdtyAkzC_Tf1Ts%2BPq%2B8g@mail.gmail.com> <20130507213118.5277F58097@chaos.jnpr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 7, 2013, at 3:31 PM, Simon J. Gerraty wrote:
>=20
> On Tue, 7 May 2013 13:05:07 -0700, Garrett Cooper writes:
>> A common pattern that I've seen at Isilon and something else that =
I've
>> wanted to have for a while is the ability to designate where the top =
of a
>> source tree was. This is important and helpful when dealing with =
source
>> files that build upon each other or depend on sources located in =
other
>=20
> FWIW I've done this in the projects/bmake branch.
>=20
> SRCTOP is the top of the src tree
> OBJTOP is the top of the corresponding obj tree
> OBJROOT is a common prefix (allows one to deduce where objects for a
> different value of $MACHINE will be).
where does MAKEOBJDIRPREFIX come into play?
> $ make -V '${SRCTOP OBJROOT OBJTOP .CURDIR =
.OBJDIR:L:@v@$v=3D${$v}@:ts\n}'
> SRCTOP=3D/b/sjg/work/FreeBSD/projects-bmake/src
> OBJROOT=3D/var/obj/projects-bmake/
> OBJTOP=3D/var/obj/projects-bmake/amd64
> .CURDIR=3D/b/sjg/work/FreeBSD/projects-bmake/src/bin/cat
> .OBJDIR=3D/var/obj/projects-bmake/amd64/bin/cat
> $
>=20
> SRCTOP is simple to derrive from where sys.mk is found
> and the others can be deduced from that
>=20
> SRCTOP:=3D ${.PARSEDIR:H:H:tA}
> OBJROOT?=3D ${SRCTOP:H}/obj/
> OBJTOP?=3D ${OBJROOT}${MACHINE}
>=20
> though since FreeBSD builds more than one MACHINE_ARCH per MACHINE (in
> some cases),=20
>=20
> OBJTOP?=3D ${OBJROOT}${MACHINE_ARCH}
>=20
> might make sense.
We do it both ways: on some architectures we have multiple =
MACHINE_ARCHes per MACHINE (like mips and arm) and on others we have one =
MACHINE_ARCH and mutliple machines (like i386 and pc98).
We currently use ${MACHINE}.${MACHINE_ARCH} for cross builds, which =
works out nicely. For historical reasons that turn out to be =
inconvenient, we don't do this for native builds.
> For Junos we had the opposite - multiple MACHINEs with same
> MACHINE_ARCH.
>=20
> I'm currently teaking projects-bmake so it can do the equivalent of
> universe so if more than one MACHINE_ARCH is possiblem the OBJTOP ends
> up being
>=20
> OBJTOP=3D ${OBJROOT}${MACHINE}-${MACHINE_ARCH}
>=20
> but for cases like i386, amd64 you just get=20
>=20
> OBJTOP=3D ${OBJROOT}${MACHINE}
>=20
> as above.
Why is this gratuitously different than the current scheme? Also, how =
would I build a pc98 build with this? And why have it be different for =
different architectures? The differences like these (although maybe not =
this one) make things harder to script for things like nanobsd that =
reach into the object tree, though the OBJTOP might be enough to solve =
that.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D6BADC3E-CCC4-4D85-8857-FB6BAAFBB820>