On May 7, 2013, at 11:41 PM, Simon J. Gerraty wrote:
>
> 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.
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 =
>> 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 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
>
>> 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"
