Re: GNU make 4.2.90 release candidate available

[Eli Zaretskii]

> From: Paul Smith <address@hidden>
> Cc: address@hidden
> Date: Wed, 28 Aug 2019 09:55:14 -0400
> 
> On Wed, 2019-08-28 at 16:25 +0300, Eli Zaretskii wrote:
> > > If they work that would be my preference, rather than adding
> > > another variable.
> > 
> > Agreed.  If you can test that, that'd be great.
> 
> I tried it and it worked with Visual Studio (to use forward-slashes in
> the source file name).

OK, the changeset I pushed uses forward slashes.

> > Do you want to keep the UMASK macro, or should we just call 'umask'
> > under the HAVE_UMASK condition?
> 
> I don't see any point in the UMASK macro if we're going to check
> HAVE_UMASK anyway.  Maybe, though, it would be nicer to create a dummy
> umask() function in misc.c if HAVE_UMASK is not defined?  That would
> avoid adding ifdefs in the code itself.

Done.

It turns out MinGW does have 'umask', so I added HAVE_UMASK to
config.h.W32.template under __MINGW32__.  The no-op function is
probably for MSVC? and maybe VMS?

> > I don't remember why we are doing this, the code has been there since
> > 2005.  Maybe so that the "Entering" and "Leaving" messages looked
> > better? seeing "make.exe[2]:" there is quite ugly.
> 
> True.  Well, no one has complained so I don't see any point in changing
> it.  Fixing this in the test suite, if we wanted to, is completely
> trivial we just need to fix the MAKE substitution in one place in the
> framework.

Can you tell me how?  That would remove quite a few failures from the
tests.