Re: 3.81 and windows paths

[Chris Taylor]

Paul D. Smith wrote:
> %% "John W. Eaton" <address@hidden> writes:
>
>   jwe> On 28-Jul-2006, Paul D. Smith wrote:
>
>   | Regardless, I still wonder whether my idea of building make for a POSIX
>   | environment with Cygwin, but setting HAVE_DOS_PATHS explicitly, would
>   | work.
>
>   jwe> If this could cause some valid Makefiles to do the wrong thing as
>   jwe> cgf suggests might happen,
>
> Hm.  I don't think I saw that message?
>
> Certainly there are obscure cases where enabling DOS path support will
> behave differently, but they're pretty rare I believe.  Is this a Cygwin
> thing?

This was a thing where POSIX compatible makefiles were not behaving as 
expected, which is now believed to be due to the cygwin dos-path 
handling patches.

>   jwe> then can we at least make the behavior optional, perhaps with a
>   jwe> command line option or magic target (maybe
>   jwe> ".WINDOWS_FILENAMES:")?
>
> This would be very tricky: right now all the code to do DOS vs. POSIX
> pathnames is controlled through #ifdefs, so it's a compile-time thing.
> Changing it to a runtime thing would be a lot of work, I think... the
> #ifdeffing in GNU make is kind of a mess, with all the different ports
> we support.
>
> Honestly, I don't see a lot of benefit to it.  On a Windows system, even
> in Cygwin, I would assume that everyone would always expect anything
> that looked like a Windows pathname to be treated like a Windows
> pathname.  We're not talking about enabling this support on UNIX, just
> in Cygwin.

Well, the whole point of cygwin is to give a POSIX-compatible 
environment in win32. So it's aiming to be like linux, not windows.
This means that if something like a makefile parses fine in linux, but 
not in cygwin (barring linker stuff), something is wrong.

And so on from there..

So even if the DOS #ifdef was enabled, we'd be back at the point of 
having patches to attempt to fix this behaviour.
Unless there was some way of having two versions of make - one with this 
behaviour and one without, controlled by /etc/alternatives perhaps?

Speculation on my part anyway.


Chris / EqUaTe