Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time

[Mike Hommey]

On Wed, Feb 05, 2014 at 05:42:17PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 5 Feb 2014 16:30:25 +0900
> > From: Mike Hommey <address@hidden>
> > Cc: Eli Zaretskii <address@hidden>, address@hidden
> > 
> > > I agree about using backslashes as directory separators, that obviously
> > > cannot work in /bin/sh, even on Windows.
> > 
> > Actually, with msys sh, it works.
> 
> But Make doesn't know about that.  When it works with a Unixy shell,
> it expects Posix file-name semantics.

But the thing is there is still inconsistency in how things end up being
invoked whether
- make calls them directly
- make uses sh -c
- make uses sh script.sh

That's barely a posix file-name semantics issue. In fact, for all
purposes, make doesn't even need to know they are file names. The most
bothering part is the inconsistency, not the fact that it considers them
as file names or not.


On Wed, Feb 05, 2014 at 05:44:18PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 5 Feb 2014 16:33:47 +0900
> > From: Mike Hommey <address@hidden>
> > Cc: address@hidden, address@hidden, address@hidden
> > 
> > On Tue, Feb 04, 2014 at 06:54:36PM +0200, Eli Zaretskii wrote:
> > > Why are you using backslashes in file names when your shell is a Unixy
> > > shell?  That makes little sense to me, and I don't see why Make on
> > > Windows should support such use.  Unixy shells are supposed to get
> > > Unixy file names with forward slashes, including in redirection.
> > 
> > I didn't write that makefile, and that makefile is just a pile of awful
> > things, not to say worse, and it does rely on the paths using
> > backslashes for many different reasons. I tried switching to forward
> > slashes, but many pieces broke as a result. The fact that I can get that
> > makefile to work with batch shell mode is kind of a deliverance: i don't
> > have to touch that pile of garbage.
> 
> I see, thanks for explaining this.
> 
> However, now I wonder why would it make sense to have this solved in
> upstream Make.  Your use case sounds rather singular, so it could be
> solved by modifying your own copy of Make, right?

I can see my unusual case as being a problem for other people too. It's
always better if you can rely on unmodified tools to get things working.
That's why I'd be totally fine with the first patch I attached, which
adds the fake target to enable the workaround at runtime instead of
buildtime. (And I wrote that patch because I don't want the horror show
to propagate unwillingly and have other makefiles silently depend on
paths with backslashes)

Mike