[Bug 283343] that -D noise again in Mk/Uses/cran.mk

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283343

--- Comment #2 from Chad Jacob Milios <milios@ccsys.com> ---
see /usr/ports/CHANGES @ 20240229 for details

TLDR;
nearly all uses of `${SETENV} ${MAKE_ENV} FOO=bar ${GMAKE} ...` or `cd
${WRKSRC}/somewhere && do-a-thing` are being deprecated for rather `${SETENVI}
${WRK_ENV} ${MAKE_ENV} FOO=bar ${GMAKE} ...` or `cd ${WRKSRC}/somewhere &&
${SETENVI} ${WRK_ENV} do-a-thing`.

(note the addition of the I to SETENVI and the explicit inclusion of WRK_ENV)

for the interested reader:

bmake (our make) supports -D to set a make variable to 1. gmake (GNU make)
stopped supporting it at some random point release a couple years ago. however,
they both set/honor the MAKEFLAGS env var for passing and inferring particular
(all?) command line options. gmake subprocesses now bork out and spectacularly
die in error with a non-useful message if the parent bmake was started with,
for instance, -DBATCH instead of BATCH=1.

tools like portmaster et al just punted, avoiding the use of -D "temporarily"
until a time that shall probably never arrive. i still like to use -DFOO -DBAR
etc to set my booleans because it helps expose where we can improve isolation
by cleaning our subprocess environments for building ports more consistently
and securely.

WRK_ENV can now be relied upon to carry that particular environment we intend
to explicitly pass down.

see also ports commit 755d190db121778a25b45950c397163325d8e797, PRs #272216,
#277492 and many others now containing SETENVI

-- 
You are receiving this mail because:
You are the assignee for the bug.