On Tue, 7 May 2013 21:25:37 -0600, Warner Losh writes:
>where does MAKEOBJDIRPREFIX come into play?
I don't normally use it, it is a handy but rather crude implement.
I normally use
MAKEOBJDIR='${.CURDIR:S,${SRCTOP},${OBJTOP},}'
which gives you a similar - but much neater result than
MAKEOBJDIRPREFIX.
>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).
Yes, which is why I'm adjusting accordingly.
>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.
>Why is this gratuitously different than the current scheme?
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 projects/bmake branch is about showing how freebsd can be built in
meta mode. The tree dependencies are represented as dir.target_spec
>would I build a pc98 build with this? And why have it be different for =
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).
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
