make381beta1

[Markus Mauhart]

Hi,


some bits about make381beta1 (from 
make.paulandlesley.org/make-3.81beta1.tar.gz):

general source branch:

*) main.c, function log_working_directory(), is missing a "fflush(stdout)"
at its end, hence e.g. all kinds of "$(warning ...)" can show during
"$(MAKE) -C somedir" before "Entering directory 'somedir'" actually shows.
I see this under mingw-builds, not cygwin-builds, regardless of make's version;
it seems that cygwin's CRTL does more internal stdout-stderr-sync than mingw's
CRTL does.

*) I think there is a bug w.r.t. target specific variables, at least my
code doesnt work. Take the following makefile:
#-----------------------
.PHONY: all

all: ;

e := E1

  $(warning e = $(e))
  .PHONY: $(e)Target
  all: $(e)Target
  $(e)Target: e := $(e)
  $(e)Target: ; @echo Making target $@ //"e" = "$(e)"

e := E2

define mkRuleForE
  $(warning Inside function mkRuleForE: e = $(e))
  .PHONY: $(e)Target
  all: $(e)Target
  $(e)Target: e := $(e)
  $(e)Target: ; @echo Making target $@ //"e" = "$(e)"
endef

e := E3

$(foreach e,e2 e3,$(warning Test run of foreach: e = $(e)))
$(foreach e,e2 e3,$(eval $(value mkRuleForE)))

e := E4

#-----------------------
IMHO the cmds run to make 'all' should display as ...

  Making target E1Target //e = E1
  Making target e2Target //e = e2
  Making target e3Target //e = e3

... but the actual result with my 381beta1 is ...


  Making target E1Target //e = E1
  Making target e2Target //e = E3
  Making target e3Target //e = E3

If this is really a bug my guess is that the definition of the
target-specific variable uses the "global variable database" instead
of the "current DB" (which is used for the rule's targets and for
its prerequisites).
So is this a bug ?
Has somebody a fix for it ?

*) Assume we have the cmdline "make -f mkfile a=aa b=bb c=cc",
and file mkfile contains a rule with the cmd "$(MAKE) -f mkfile c=CC d=DD e=EE".
Then inside the executed sub-make, "$(MAKEOVERRIDES)" evaluates to ...
"e=EE d=DD c=CC a=aa b=bb c=CC".
So the strange and redundant thing is that the variable named 'c' comes twice,
and the same holds for all variables that are assigned on both command lines
(of original make and of submake), especially uncomfortable if the values
and|or names are not so simple and short as "c" and "CC".


MINGW specific sources:

*) dir.c contains ...
#ifdef __MINGW32__
# if __MINGW32_VERSION_MAJOR < 3 || (__MINGW32_VERSION_MAJOR == 3 && \
         __MINGW32_VERSION_MINOR == 0)
   d->d_name = xmalloc(len);
# endif
#endif

.. but the correct names are __MINGW32_MAJOR_VERSION and 
__MINGW32_MINOR_VERSION,
at least according to mingw32-make-3.80.0-3-src.tar.bz2, 
mingw-runtime-3.7.tar.gz
and mingw-runtime-3.5.tar.gz.

*) w32/sub_proc/sub_proc.c fails to compile under msys+mingw-gcc342, cause 
function
"process_file_io" is used before beeing declared. The reason for the missing
declaration is that w32/sub_proc/sub_proc.c does include 
w32/sub_proc/sub_proc.h,
but sub_proc.h uses macro WINDOWS32 without including <config.h>;
sub_proc.c itself includes "config.h", but too late for sub_proc.h.
For a solution one could un-use macro WINDOWS32 in sub_proc.h
,or let sub_proc.h include <config.h>
,or let sub_proc.cpp include <config.h> before including sub_proc.h
,or ...


Regards,
Markus.