M*K**BJD*RPR*F*X and make.conf

From: Barry Bouwsma <freebsd-misuser_at_remove-NOSPAM-to-reply.NOSPAM.dyndns.dk>
Date: Sat, 28 Aug 2004 19:00:26 +0200 (CEST)
[grrr, last IP was blacklisted; try the list again]

Hi.  You're going to hate me by the end of this message,
in the unlikely chance that you don't hate me already.

If I'm reading the failure of my attempted crossbuild of
FreeBSD5 on my FBSD-4 machine, the check in Makefile.inc1
is not looking in the right __MAKE_CONF, which I've tried
specifying both as environment and make-option to cover
all bases.

Instead, it's looking in /etc/make.conf, which as far as I know
is never used during my crossbuild (I hope), and where as far as
I know it's still not expressly forbidden to use M*K**BJetc ?= foo
at the present time under 4.x ...

I've tried the following for fun and laughs, and it actually
seems to pick up the right values for M_K__BJD_RPR_F_X (I'm
sure nobody wants to read the uncensored version of that for
weeks or months to come), allowing my build to continue:

_MAKEOBJDIRPREFIX!= env -i PATH=${PATH} __MAKE_CONF="${__MAKE_CONF}" \
                MAKEFLAGS="${.MAKEFLAGS}" ${MAKE} \
                -f /dev/null -V MAKEOBJDIRPREFIX dummy
.if !empty(_MAKEOBJDIRPREFIX)

May I request that something done properly (unlike the above
which is certainly no more than an ugly hack) be applied in
order to check the correct file for crossbuilds or other
cases where __MAKE_CONF is specified instead?

Sorry if this has been done already, my last time online to
nab source was late UTC 22.Aug.


I fully understand that you hate me now.

thanks
barry bouwsma

(to rehash a previous thread, here's another reason I liked to be
able to specify M*K**BJD*RPR*F*X in a make.conf, is in order to
automagically get a different obj directory for each build, by
evaluating `uname' and `date' and whatnot, which now requires an
each-time invocation as environment, unlike the set-and-forget in
a suitable make.conf.  no, I haven't tried my hand at suitably
replacing this (mis)feature in an acceptable way yet)
Received on Sat Aug 28 2004 - 15:00:46 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:09 UTC