On Friday, 04.03.2016 at 16:05, Antti Kantee wrote:
> On 04/03/16 15:38, Martin Lucina wrote:
> >Two patches here, one for rumprun (the user of these variables), another
> >for src-netbsd. Please review. Fixes rumprun issue #38 (build fails on
> >certain distros with dash as /bin/sh).
>
> Those variables the current public "API", so I'd not remove the old
> variables, just += the new ones.
Not sure if that's possible. RUMPCOMP_USER_PATH is used to set .PATH, which
according to the make documentation must be updated by setting the .PATH
target, so there's no easy way to do +=.
Perhaps just bite the bullet, change the names and other users of the API
will need to change ...?
> Just to be sure, did you build and runtest the patch? (I can't easily test
> it myself, so I'll be committing blind)
Yes.
>
> >Who are the other downstream users that may be affected by this change?
>
> What do you mean by "downstram users"?
What I meant was "does this change break an API (the variable names) which
will affect users other than rumprun"?
>
> >Related, while looking at the output from my instrumeted copy of 'dash',
> >the following code at nbmake main.c:996 is suspect:
> >
> > /* some makefiles need to know this */
> > Var_Set(MAKE_LEVEL ".ENV", MAKE_LEVEL_ENV, VAR_CMD, 0);
> >
> >Using VAR_CMD here causes an underlying call to setenv(".MAKE.LEVEL.ENV",
> >MAKE_LEVEL_ENV). Should the call to Var_Set() use VAR_GLOBAL instead? There
> >doesn't seem to be any point in exporting ".MAKE.LEVEL.ENV=MAKELEVEL" given
> >that it's set anew on each invocation of make and POSIX-compliant shells
> >may refuse to set the variable anyway.
>
> If you think it's a problem, better bring it up on
> [email protected].
Ok.
