[Mingw-users] Re: GNU make 3.80rc1: porting to MinGW-MSYS

[Soren A <sor...@fa...>]

Earnie Boyd <ear...@ya...> wrote in
news:3D7...@ya...: 

> How does the coding for this version differ from the previous version
> in respect to spawning processes for Win32.  Previously, it searched
> for an available sh.exe and if not found resorted to dos batch files. 
> This in itself caused for great discomfort and often a Makefile would
> not be properly represented to make?
> 
> Also, does the Win32 (either __MINGW32__ or _WIN32, etc.) affect the
> other improvements that were made in the code, or do the preprocessor
> filters eliminate the new improvements for the native version?  I ask
> due to the limitations found with the current 3.79.1 version
> downloadable from the sf.net site for the MinGW project.  Those
> limitations are the reason I include a msys-1.0 dependent version in
> the MSYS distribution. 

I wish i could be of greater use in being able to answer either question
in an authoritative and precise manner -- but alas I cannot. What i can
say is that not having come across anything to suggest the contrary, I
think the Win32-specific parts of 'make-3.80rc1' have been left largely
untouched (unimproved) and that's one reason why i am 'calling' for
expressions of interest and involvement now. I think that it's possible,
at least it hasn't yet been ruled out, that Paul Smith might be
interested in including improvements in this area in a final release;
but if those improvements take too much longer in coming to his
attention / being submitted for his review, i suppose he might well
prefer to wait to include them in some much later future release
instead. You know how it is. 

The interest and involvement, i would say, from becoming subscribed to
the make mailing list(s) ["bug-make -AT- gnu.org", "help-make -AT-
gnu.org"] that 'works' is just to get on the list and ask Paul for what
you need to have included / changed in 'make'. People on obscure *nix
hardware that i've never heard of are asking for and getting Paul's help
in addressing relatively subtle performance issues on their platforms.
How come MinGW / Free Win32 hackers have to work with 'make'
difficulties that never improve except by working out semi-private
branches of the code? Maybe because for Paul Smith we aren't visible
enough. Or maybe he hates Windozen, I cannot rule that out, but the guy
seems affable and responsive and non-insan-o as far as I can tell. 

I hardly need to tell YOU any of this, i think, Earnie, because I see
your postings on all sorts of Lists like the Automake/autoconf Lists and
I think you've been very active in seeking to engage / learn /
contribute with phases of programming that impact on MSYS' success and
improvement. So my little suggestions are just general musings and maybe
somebody else who, unlike yourself, hadn't thought along these lines
before (didn't "get it" yet) but wants 'make' to work better, will find
the suggestion useful. 

As far as the cpp macros, I cannot tell yet how much of any parallel-job
performance or sub-process spawning performance improvement that might
be in this upcoming release are in effect for Win32. I can tell you that
mostly, other things that are improvements (although maybe of a lesser
sort) seem to work fine on Win32. 

The main macro for Win32-specific code in the 'make' package seems to be
"WINDOWS32", btw. 

  Best,
    Soren A