Re: Environment settings not taken into account by (portable) bmake(1)?(!)

[Steffen Nurpmeso <steffen%sdaoden.eu@localhost>]

Taylor R Campbell <campbell+netbsd-tech-userlevel%mumble.net@localhost> wrote:
 |   Date: Sat, 05 Nov 2016 18:47:54 +0100
 |   From: Steffen Nurpmeso <steffen%sdaoden.eu@localhost>
 |
 |   I am currently fixing the build system of the MUA i maintain
 |   because the portable version of bmake looses CFLAGS (and LDFLAGS
 |   i think) from the environment.
 |
 |Can you share a small isolated example that demonstrates the problem
 |you're observing?  Certainly bmake does respect environment variables
 |for make macro expansion:
 |
 |% printf 'x:;@echo ${CFLAGS}' | CFLAGS=abcd bmake -f /dev/stdin
 |abcd
 |% printf 'x:;@echo ${CFLAGS}' | bmake -f /dev/stdin CFLAGS=abcd
 |abcd
 |
 |However, following POSIX, any assignments in the makefile itself
 |override environment variables, unless you use the -e option:
 ...

There are no assignments, the file is

  .SUFFIXES: .o .c .x .y
  .c.o:
          $(CC) -I./ $(CFLAGS) -c $(<)
  .c.x:
          $(CC) -I./ -E $(<) > $(@)
  .c:
          $(CC) -I./ $(CFLAGS) $(LDFLAGS) -o $(@) $(<)

But i see now that i already have needed such a fix two years back
for cross-compilation on Void Linux!  The commit message reads

  ...
      - make PREFIX=/usr ...
      + make CC=$CC PREFIX=/usr ...

    i finally assume that environment variables that are defined by
    make(1) itself by definition are not passed through to
    subprocesses by the used make(1) but instead reset to the make(1)
    default-ones.  I have seen similar problems for S-CText, fixed
    there for example on 2014-04-14 in [7cc84aa] by explicitly setting
    the variable (as shown above) when calling those.

    Let's see if that fixes Void Linux.  If not i think we either have
    to document this problem (as for UnixWare where you have to pass
    -e, but which has unfortunate side-effects) or even replace the
  ...

and i think the standard leaves that undefined.  Note however that
this fix was for a make(1) rule invoking $(SHELL) which in turn
starts other $(MAKE) instances (the fix was

  -_prego = $(SHELL) ./mk-conf.sh
  +_prego = SHELL="$(SHELL)" MAKE="$(MAKE)" \
  +       CC="$(CC)" CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)" \
  +       $(SHELL) ./mk-conf.sh

back then) but this time there is a direct invocation:

  compile_check() {
     variable=$1 topic=$2 define=$3

     _check_preface "${variable}" "${topic}" "${define}"

     if ${make} -f ${makefile} XINCS="${INCS}" \
^^^ $make==bmake, $makefile as above
              CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}" \
^^^ this line new and fixes issue
              ./${tmp}.o &&
           [ -f ./${tmp}.o ]; then
        msg 'yes'

and then i think this is not quite right given that CFLAGS and
LDFLAGS are exported into the environment.  I.e., my ~/.profile
exports CFLAGS='-01 -g' by default and i would be surprised if
that isn't inherited!  So the attached test program yields

  ?0[steffen@wales tmp]$ make=make sh bm.sh
  clang -I./ -g -O -g -DBLA="-g -O -g" -o bm bm.c
  ok
  ?0[steffen@wales tmp]$ make=smake sh bm.sh
  ...clang -I./ -g -O -g -DBLA="-g -O -g" -o bm bm.c
  ok
  ?0[steffen@wales tmp]$ make=bmake sh bm.sh
  cc -pipe -I./ -g -DBLA="-g" -o bm bm.c
  no

Ciao.

--steffen

Attachment: bm.sh
Description: Bourne shell script