I discovered that a control build 'gnumake debug_build' is NOT really a complete debug build. The j2se is some kind of half and half beast when build as a debug build from the control workspace. The hotspot build was fine and building the debug j2se directly from the j2se makefiles seems fine, e.g. cd j2se/make; gnumake debug.

This was tricky to figure out so I isolated it down to a small testcase to show what is happening:

The control makefiles effectively do line 3, the file control/make/j2se-rules.gmk uses MAKEFLAGS= to empty out what is sent down into a makefile (or that's what I assume someone was trying to do):

> cat -n Makefile
     1 all:
     2 ( cd xxx ; $(MAKE) all VARIANT=DBG ; )
     3 ( cd xxx ; $(MAKE) all MAKEFLAGS= VARIANT=DBG ; )


The j2se makefile looks something like this:

> cat -n xxx/Makefile
     1 VARIANT=OPT
     2 all:
     3 echo "VARIANT=$(VARIANT)"
     4 $(MAKE) xxx
     5 xxx:
     6 echo "VARIANT=$(VARIANT)"

When you run it you get:

ntk<44> gnumake
( cd xxx ; gnumake all VARIANT=DBG ; )
gnumake[1]: Entering directory `/home/ohair/xxx'
echo "VARIANT=DBG"
VARIANT=DBG
gnumake xxx
gnumake[2]: Entering directory `/home/ohair/xxx'
echo "VARIANT=DBG"
VARIANT=DBG
gnumake[2]: Leaving directory `/home/ohair/xxx'
gnumake[1]: Leaving directory `/home/ohair/xxx'

The above is fine... VARIANT is passed around with the top level value. But look what happens next:

( cd xxx ; gnumake all MAKEFLAGS= VARIANT=DBG ; )
gnumake[1]: Entering directory `/home/ohair/xxx'
echo "VARIANT=DBG"
VARIANT=DBG
gnumake xxx
gnumake[2]: Entering directory `/home/ohair/xxx'
echo "VARIANT=OPT"
VARIANT=OPT
gnumake[2]: Leaving directory `/home/ohair/xxx'
gnumake[1]: Leaving directory `/home/ohair/xxx'

Sending down MAKEFLAGS= is preventing the next level MAKE from sending anything at all down into the j2se nested makefile, letting VARIANT defer to the default value. The top level got the VARIANT=DBG, but sub makefiles did not. This is the problem with the control debug builds.

The use of MAKEFLAGS= is probably a huge mistake, but I don't have enough history to know WHY it was used, it has this second order effect on the recursive makefiles that seems really problematic. There is a bug asking that make variables be passed down and this bug is rooted in the use of MAKEFLAGS=. I hadn't fixed this because I didn't know why this was done. I do know that when going from gnumake to nmake on windows, the MAKEFLAGS= is important because the syntax of the words in MAKEFLAGS is different for nmake and it will crash, other than that, I don't see any reason to use MAKEFLAGS=, but it's hard to tell. There might be some risk that at the top level control build says FOOBAR=goodie, and deep down a lower level Makefile is using FOOBAR to mean something completely different, but that risk seems minimal. My conclusion is that all this MAKEFLAGS= uses should be removed (except where needed with nmake) and then many of the places where we explicitly pass things down with every use of '$(MAKE)' can probably be simplified too.

FASTDEBUG was not a problem because it is never defined in the makefiles, so the setting seems to be inherited via the top level makefile environment variables. And since the j2se makefiles explicitly set VARIANT=DBG when it sees FASTDEBUG=true, then the fastdebug control builds are fine.

-kto