Re: make distclean and quail

[Eli Zaretskii <eliz@gnu.org>]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 11 Aug 2013 19:49:43 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> On Sun, Aug 11, 2013 at 7:17 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > So you are saying that _all_ of the Makefile's set srcdir to its
> > correct value
> 
> Yes, all Makefiles have srcdir = /c/Devel/emacs/repo/trunk [etc],
> 
> > and yet the commands issued by Make have "Devel"
> > downcased, is that right?
> 
> The "Entering directory" / "Leaving directory" messages are correctly
> cased, as are many commands:

The entering/leaving messages are entirely unrelated, as they don't
involve expanding Make variables.

>   /c/Devel/emacs/build/bin/makeinfo --force
> -I/c/Devel/emacs/repo/trunk/doc/misc/../emacs [etc]
> 
>   gcc  -std=gnu99 -mtune=pentium4 [deleted warnings stuff] -I.
> -I/c/Devel/emacs/repo/trunk/nt  -Lc:/Devel/emacs/lib -mtune=pentium4
> -Ic:/Devel/emacs/include -DUSE_CRT_DLL=1 -I
> /c/Devel/emacs/repo/trunk/nt/inc -O0 -g3
> /c/Devel/emacs/repo/trunk/nt/runemacs.c
> 
> However "shell" commands are not:
> 
>   [ -r "/c/devel/emacs/repo/trunk/src/config.in" ] || ( cd
> /c/devel/emacs/repo/trunk && autoheader )
> 
>   if test -f "/c/devel/emacs/repo/trunk/src/.gdbinit"; then rm -f
> ./.gdbinit.save; \

Could it be that those that are downcased are all in quotes?

> > That kinda blames Make and it alone,
> > because it is Make who expands variables when it invokes commands.
> > Did you try to install a newer snapshot of MSYS Make?
> 
> I'm using the one I installed originally from here:
> https://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/
> 
>   C:\...\repo> \bin\MinGW\msys\1.0\bin\make.exe --version
>   GNU Make 3.82.90
>   Built for i686-pc-msys

Maybe try a newer one.

> > And you also say that this happens only sometimes?
> 
> Yes. Perhaps when a reconfiguration is triggered

But all the reconfiguration does is regenerate Makefile's, and you say
they all come out OK.

And reconfiguration is triggered very often these days, so you should
have seen this more frequently.

Perhaps you should always create a log of a build (e.g., with 'tee'),
and collect those that fail like this.  Then, when you have a few, we
could see what do they have in common.

> Well, I certainly can rename C:/Devel to C:/devel and not to worry
> again, but it is still quite puzzling why does it happens only part of
> the time.

I think it's just a subtle bug, all it is.