Date: Wed, 8 May 2013 15:49:12 -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: <9CD1CE3E-C17C-4C63-BA03-190531185D7A@bsdimp.com> In-Reply-To: <20130508054121.DCA7258097@chaos.jnpr.net> References: <CAGH67wS21otQr1fBqQ2z=XQjUV30QUjdtyAkzC_Tf1Ts%2BPq%2B8g@mail.gmail.com> <20130507213118.5277F58097@chaos.jnpr.net> <D6BADC3E-CCC4-4D85-8857-FB6BAAFBB820@bsdimp.com> <20130508054121.DCA7258097@chaos.jnpr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 7, 2013, at 11:41 PM, Simon J. Gerraty wrote:
>=20
> On Tue, 7 May 2013 21:25:37 -0600, Warner Losh writes:
>> where does MAKEOBJDIRPREFIX come into play?
>=20
> I don't normally use it, it is a handy but rather crude implement.
> I normally use=20
>=20
> MAKEOBJDIR=3D'${.CURDIR:S,${SRCTOP},${OBJTOP},}'
>=20
> which gives you a similar - but much neater result than
> MAKEOBJDIRPREFIX.
Isn't that backwards. MAKEOBJDIRPREFIX in today's FreeBSD is much more =
like OBJTOP than what you've quoted here. That's how I set the top of =
the tree today, usually with a 'setenv MAKEOBJDIRPREFIX $HOME/obj' in my =
.cshrc so it is always active. That way I can just buildworld or =
buildkernel without having to worry where things will wind up, or having =
problems with /usr/obj being unwritable... I know this trick doesn't =
work for netbsd's make (or didn't years ago when I was building it on a =
regular basis), so I assume it is FreeBSD make centric.
>> We do it both ways: on some architectures we have multiple =3D
>> MACHINE_ARCHes per MACHINE (like mips and arm) and on others we have =
one =3D
>> MACHINE_ARCH and mutliple machines (like i386 and pc98).
>=20
> Yes, which is why I'm adjusting accordingly.
>=20
>> We currently use ${MACHINE}.${MACHINE_ARCH} for cross builds, which =3D=
>> works out nicely. For historical reasons that turn out to be =3D
>> inconvenient, we don't do this for native builds.
>=20
>> Why is this gratuitously different than the current scheme?=20
>=20
> Do you mean why not simply use ${MACHINE}.${MACHINE_ARCH} always?
> Encoding both MACHINE and MACHINE_ARCH always is doable, but I avoid =
'.'
> because it prevents being able to use modifiers like :R and :E
> to separate the directory component from the target machine spec.
The project currently uses dots without issue. Not quite sure why you'd =
need to generate things that way. Sure it sounds useful, but it seems =
rather a backwards way to work out MACHINE and MACHINE_ARCH (or I'm =
misunderstanding what you are saying).
> The projects/bmake branch is about showing how freebsd can be built in
> meta mode. The tree dependencies are represented as dir.target_spec
>=20
>> would I build a pc98 build with this? And why have it be different =
for =3D
>=20
> it would just get pc98 since there's no ambiguity.
> But as noted above, if you wanted to always be explicit that wouldn't =
be
> a problem (assuming '.' is avoided).
>=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9CD1CE3E-C17C-4C63-BA03-190531185D7A>