Why are Windows paths broken in make 3.81?

Why are Windows paths broken in make 3.81?

[Michael Hirsch]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

Here is a sample Makefile that breaks with Gnu Make 3.81-1 under
Cygwin, but works fine with Gnu Make 3.80-1.  We have been writing
these types of Makefiles for years, using both Windows and Cygwin
tools, and this is the first time Make has ever broken like this.

I see in another thread that this is a known issue, though I don't see
it in the changelogs for make 3.81.

Was this a deliberate break with backwards compatibility?  It means
that every single reference to a windows path needs to be wrapped in
cygpath, which is a huge inconvenience.

Is it broken only on Windows?  Since ':' is a legal file character in
unix I wouldn't expect this to  be a problem in the gnu make sources.
Is this a cywin only bug?  What possible reason could there be to
introduce this deliberately?

Confusedly yours,

Michael

[-- Attachment #2: cygcheck.out --]
[-- Type: application/octet-stream, Size: 47151 bytes --]

[-- Attachment #3: Makefile --]
[-- Type: application/octet-stream, Size: 159 bytes --]

SOURCE=foo
TARGET:=c:/temp/$(SOURCE)

default: $(TARGET)

$(SOURCE):
	touch $@

$(TARGET): $(SOURCE)
	cp $< $@

clean:
	rm -f $(SOURCE) $(TARGET)

[-- Attachment #4: Type: text/plain, Size: 218 bytes --]

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[mwoehlke]

Michael Hirsch wrote:
> Here is a sample Makefile that breaks with Gnu Make 3.81-1 under
> Cygwin, but works fine with Gnu Make 3.80-1.  We have been writing
> these types of Makefiles for years, using both Windows and Cygwin
> tools, and this is the first time Make has ever broken like this.
> 
> I see in another thread that this is a known issue, though I don't see
> it in the changelogs for make 3.81.
> 
> Was this a deliberate break with backwards compatibility?  It means
> that every single reference to a windows path needs to be wrapped in
> cygpath, which is a huge inconvenience.

Yes. See <http://cygwin.com/ml/cygwin-announce/2006-07/msg00008.html>. 
If you are using a POSIX-like "OS" (i.e. Cygwin), you should be using 
POSIX paths. That's not an inconvenience, that's called writing a bad 
makefile. If you aren't using Cygwin for the POSIX environment, you 
should be using MinGW.

> Is it broken only on Windows?

That sounds like a silly question... 'are Windows paths only broken on 
Windows?'

> Is this a cywin only bug?  What possible reason could there be to
> introduce this deliberately?

No, as it is not a "bug". However it is specific to Cygwin. See the 
aforementioned announcement. CGF would have to speak to "why" (and I 
would appreciate if he would, just because I am curious :-)), but I 
would guess it is to "encourage" people to use correct (i.e. POSIX) paths.

-- 
Matthew
Doom doom dooM doo-DooM dOOm DOom doOM... DOOM! -- Gir


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Joachim Achtzehnter]

mwoehlke wrote:

> Michael Hirsch wrote:
>> Here is a sample Makefile that breaks with Gnu Make 3.81-1 under
>> Cygwin, but works fine with Gnu Make 3.80-1.
>> ...
>> Was this a deliberate break with backwards compatibility?  It means
>> that every single reference to a windows path needs to be wrapped in
>> cygpath, which is a huge inconvenience.
> 
> Yes. See <http://cygwin.com/ml/cygwin-announce/2006-07/msg00008.html>. 
> If you are using a POSIX-like "OS" (i.e. Cygwin), you should be using 
> POSIX paths. That's not an inconvenience, that's called writing a bad 
> makefile.

I would dispute the contention that this change is "not an inconvenience". 
It is a major inconvenience and the problems are not just due to "writing a 
bad makefile".

If one was just dealing with a bunch of small makefiles that one has 
"written" or could easily re-write it wouldn't be a big deal.

Unfortunately, many of us deal with huge cross-platform 3rd-party makefile 
collections that are partially auto-generated, sometimes even on-the-fly, 
i.e. commands in one makefile generate (portions of) other makefiles using 
tools like sed and invoking many subsidiary tools like IDL compilers and 
various pre-processors in the process.

I just had to deal with such a messy system and the new Cygwin make doesn't 
work. Even though this collection of makefiles was initially written on a 
POSIX system it still got into trouble with DOS paths because some of the 
tools it calls to generate makefiles return platform-specific paths. So 
this works fine on a POSIX system, worked fine on Win2000 with the old 
make, but now I had to understand complicated sed programs to add extra 
platform-specific sed transformations to convert paths returned by other 
cross-platform tools to something the new make accepts.

There was also some difference in newline handling which required another 
set of sed changes, arghh!

All of this was definitely inconvenient! And it was not caused by somebody 
putting non-POSIX paths in a makefile.

Of course, after fixing all this it still doesn't work, as mentioned in 
another post, make crashes with threadlist_ix -1, so I still have to go 
back to the older version, even after all the work. :-(

Joachim

-- 
work:     joachima@netacquire.com   (http://www.netacquire.com)
private:  joachim@kraut.ca          (http://www.kraut.ca)

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Christopher Faylor]

On Fri, Jul 21, 2006 at 05:29:16PM -0600, Michael Hirsch wrote:
>Here is a sample Makefile that breaks with Gnu Make 3.81-1 under
>Cygwin, but works fine with Gnu Make 3.80-1.  We have been writing
>these types of Makefiles for years, using both Windows and Cygwin
>tools, and this is the first time Make has ever broken like this.
>
>I see in another thread that this is a known issue, though I don't see
>it in the changelogs for make 3.81.

Huh?  It was mentioned in the release announcement.  You wouldn't see
the changes in any official make changelogs since the patches were never
in the official version of make.

>Was this a deliberate break with backwards compatibility?

Since it was mentioned in the release announcement, you can safely assume
that it was deliberate.

>It means that every single reference to a windows path needs to be
>wrapped in cygpath, which is a huge inconvenience.

Or, you could investigate the mingw verison of make, as was mentioned in
the release announcement.

Hmm.  A pattern seems to be developing.

>Is it broken only on Windows?  Since ':' is a legal file character in
>unix I wouldn't expect this to  be a problem in the gnu make sources.
>Is this a cywin only bug?  What possible reason could there be to
>introduce this deliberately?

I participate in cygwin because I like providing a linux-like interface
on Windows.  I have no personal interest in standing on my head to
maintain MS-DOS filenames in utilities which do not already support them
out of the box.  By foregoing the pain of forward porting the cygwin
MS-DOS patches, I can release new versions of make with minimal effort.
This benefits all of the people who are using the tool "correctly" with
POSIX-like paths.

(Yes, I know I could have submitted the patches upstream long ago but I
would still end up maintaining this hack regardless)

If this is unacceptable then feel free to stay on the previous version of
make.exe, use the mingw version, or even roll your own.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Christopher Faylor]

On Fri, Jul 21, 2006 at 06:03:43PM -0700, Joachim Achtzehnter wrote:
>There was also some difference in newline handling which required another 
>set of sed changes, arghh!

Well with detailed bug reports like this and the previous "make provides an
error on one of my complex makefiles" we're surely well on the road towards
perfection.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Larry Hall (Cygwin)]

On 07/21/2006, Joachim Achtzehnter wrote:
> I just had to deal with such a messy system and the new Cygwin make doesn't 
> work. Even though this collection of makefiles was initially written on a 
> POSIX system it still got into trouble with DOS paths because some of the 
> tools it calls to generate makefiles return platform-specific paths. So 
> this works fine on a POSIX system, worked fine on Win2000 with the old 
> make, but now I had to understand complicated sed programs to add extra 
> platform-specific sed transformations to convert paths returned by other 
> cross-platform tools to something the new make accepts.
> 


Did you think about using 'cygpath' on the result instead of adding extra
platform specific transformations to your complicated sed programs?



-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Joachim Achtzehnter]

Hi all,

Christopher Faylor wrote:

> On Fri, Jul 21, 2006 at 06:03:43PM -0700, Joachim Achtzehnter wrote:
>> There was also some difference in newline handling which required another 
>> set of sed changes, arghh!
> 
> Well with detailed bug reports like this and the previous "make provides an
> error on one of my complex makefiles" we're surely well on the road towards
> perfection.

This sarcastic response to one sentence out of a much longer post quoted in 
isolation suggests that a clarification is in order. Neither of my previous 
posts, not the one about the "threadlist_ix -1" error and not the one I 
wrote specifically in response to a claim that the recent changes to make 
were "not an inconvenience", were written with any expectations for a fix. 
I do understand free software, I'm not paying anybody, hence I can have no 
expectation of somebody doing work for me.

I wrote the first post (about "threadlist_ix -1") in case this particular 
error message rings a bell given that the recent changes that must have 
caused it are likely fresh in the minds of developers, i.e. trying to be 
helpful. If it isn't anything obvious, clearly more detailed debugging 
would be needed, something that won't be altogether easy given that it 
occurs in makefiles that are complex and of which I know very little how 
everything works (lots of scripting to generate make rules on the fly, so 
it isn't even easy to see what the makefiles that ultimately get processed 
by make contain without a lot of sleuthing).

My second post was specifically in response to the claim by mwoehlke 
suggesting that the changes were "not an inconvenience". In this post all 
the issues I mentioned were intended as illustrations of such 
inconveniences, so there was even less implied expectation of somebody 
acting on these. Note, that I wrote that I had already addressed the issues 
caused by deliberate incompatibilities, all I intended to do was point out 
that it *had been* inconvenient.

So sum up, you are the people doing the work, I'm not funding your work, so 
all decisions are yours. You may or may not take into account that at least 
some users are likely to be inconvenienced by some of these decisions, and 
especially those using Cygwin as a tool for achieving cross-platform 
portability of large complex systems, of which they sometimes know very 
little (they will now have to understand more to get things working again).

Thanks for providing these tools, and thanks also to those who posted 
possible solutions for some of these issues. As I wrote, in this case I had 
already managed to address all issues related to the functional changes in 
make, only the internal error remains (and at present it is still easy to 
use the older make, which may change as we go forward).

Joachim

-- 
work:     joachima@netacquire.com   (http://www.netacquire.com)
private:  joachim@kraut.ca          (http://www.kraut.ca)

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Mark Fisher]

On 7/24/06, Joachim Achtzehnter <joachima@netacquire.com> wrote:
> This sarcastic response to one sentence out of a much longer post quoted in
> isolation suggests that a clarification is in order.

here here! i'd like to add that i'm getting fed up of reading sarcastic
comments from cgf since i rejoined the mailing list.

this particular gem:

>>I assumed the compiled program would work in a bash
>>shell but it only works in a dos shell-its too late to
>>worry about why that is. I miss unix.
>
>Yeah, things work a lot better in a dos shell on unix.
( http://cygwin.com/ml/cygwin/2006-07/msg00682.html )

the sole comment to an entire post sums up for me a very
arrogant attitude towards people with less knowledge who
need help.

this forum (i hope) was never meant as a personal sarcasm
area and to read it it's very annoying.

if you don't have something constructive to say, lay off laying
into people.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

CGF gripes; was -> Re: Why are Windows paths broken in make 3.81?

[Larry Hall (Cygwin)]

Mark Fisher wrote:
> On 7/24/06, Joachim Achtzehnter <joachima@netacquire.com> wrote:
>> This sarcastic response to one sentence out of a much longer post 
>> quoted in
>> isolation suggests that a clarification is in order.
> 
> here here! i'd like to add that i'm getting fed up of reading sarcastic
> comments from cgf since i rejoined the mailing list.
> 
> this particular gem:
> 
>>> I assumed the compiled program would work in a bash
>>> shell but it only works in a dos shell-its too late to
>>> worry about why that is. I miss unix.
>>
>> Yeah, things work a lot better in a dos shell on unix.
> ( http://cygwin.com/ml/cygwin/2006-07/msg00682.html )
> 
> the sole comment to an entire post sums up for me a very
> arrogant attitude towards people with less knowledge who
> need help.
> 
> this forum (i hope) was never meant as a personal sarcasm
> area and to read it it's very annoying.
> 
> if you don't have something constructive to say, lay off laying
> into people.


For your own peace of mind while reading the list, put a :-) or
;-) after everything you read from cgf and it becomes hilarious.
As it turns out, that's sometimes even the intent. ;-)

Since a continuation of the thread in this new direction is really
off-topic for this list, I'd suggest if you have a follow-up that
you'd like to make or if there are others that would like to, it's
best to <http://cygwin.com/acronyms/#TITTTL>.   I've reset the "Reply-To"
to facilitate the move.

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[mwoehlke]

Joachim Achtzehnter wrote:
> Christopher Faylor wrote:
>> On Fri, Jul 21, 2006 at 06:03:43PM -0700, Joachim Achtzehnter wrote:
> My second post was specifically in response to the claim by mwoehlke 
> suggesting that the changes were "not an inconvenience". In this post 
> all the issues I mentioned were intended as illustrations of such 
> inconveniences, so there was even less implied expectation of somebody 
> acting on these. Note, that I wrote that I had already addressed the 
> issues caused by deliberate incompatibilities, all I intended to do was 
> point out that it *had been* inconvenient.

For the record, I was just trying to point out that the general 
consensus around here seems to be 'don't use DOS paths in Cygwin', and 
was using that to explain what I feel to be one major reason for the 
change. I accept and acknowledge that this change may be inconvenient 
for some people, but it is also my opinion that if you are affected by 
it, you are doing something that was never condoned or officially 
supported in the first place. (And, after all, WJM. ;-))

I am glad you got things working and (I assume, since you say things are 
working) looking POSIX-like.

Personally, every time I see mention of someone using DOS paths in 
Cygwin, or a Cygwin program, I wonder to myself why this works at all :-).

-- 
Matthew
Warning: This message has not been approved by the FDA.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Why are Windows paths broken in make 3.81?

[Dave Korn]

On 22 July 2006 02:04, Joachim Achtzehnter wrote:

> mwoehlke wrote:

>> Michael Hirsch wrote:

>>> Here is a sample Makefile that breaks with Gnu Make 3.81-1 under
>>> Cygwin, but works fine with Gnu Make 3.80-1.
>>>               [ ... snip ... ]
>>> Was this a deliberate break with backwards compatibility?  

>> Yes. See <http://cygwin.com/ml/cygwin-announce/2006-07/msg00008.html>.

> Unfortunately, many of us deal with huge cross-platform 3rd-party makefile
> collections that are partially auto-generated, sometimes even on-the-fly,

> I just had to deal with such a messy system and the new Cygwin make doesn't
> work. Even though this collection of makefiles was initially written on a
> POSIX system it still got into trouble with DOS paths because some of the
> tools it calls to generate makefiles return platform-specific paths. So
> this works fine on a POSIX system, worked fine on Win2000 with the old
> make, but now I had to understand complicated sed programs to add extra
> platform-specific sed transformations to convert paths returned by other
> cross-platform tools to something the new make accepts.
> 
> There was also some difference in newline handling which required another
> set of sed changes, arghh!
> 
> All of this was definitely inconvenient! And it was not caused by somebody
> putting non-POSIX paths in a makefile.

  Well, to be fair, it was caused by someone implementing a system that made
use of utilities that put non-POSIX paths in a makefile.  It didn't 'just
happen', it was the consequence of a deliberate set of design and
toolset-selection decisions.
 
> Of course, after fixing all this it still doesn't work, as mentioned in
> another post, make crashes with threadlist_ix -1, so I still have to go
> back to the older version, even after all the work. :-(

  Which begs the question: given that you were working on such a large and
complex makefile system, and given that it had non-POSIX paths in a makefile,
and given that it wasn't broke and didn't need fixing ...

...  why on EARTH did you deliberately go and upgrade to a new version of make
that doesn't support non-POSIX paths?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Christopher Faylor]

On Mon, Jul 24, 2006 at 01:01:55PM -0500, mwoehlke wrote:
>Joachim Achtzehnter wrote:
>>Christopher Faylor wrote:
>>>On Fri, Jul 21, 2006 at 06:03:43PM -0700, Joachim Achtzehnter wrote:
>>My second post was specifically in response to the claim by mwoehlke 
>>suggesting that the changes were "not an inconvenience". In this post 
>>all the issues I mentioned were intended as illustrations of such 
>>inconveniences, so there was even less implied expectation of somebody 
>>acting on these. Note, that I wrote that I had already addressed the 
>>issues caused by deliberate incompatibilities, all I intended to do was 
>>point out that it *had been* inconvenient.
>
>For the record, I was just trying to point out that the general 
>consensus around here seems to be 'don't use DOS paths in Cygwin', and 
>was using that to explain what I feel to be one major reason for the 
>change. I accept and acknowledge that this change may be inconvenient 
>for some people, but it is also my opinion that if you are affected by 
>it, you are doing something that was never condoned or officially 
>supported in the first place. (And, after all, WJM. ;-))
>
>I am glad you got things working and (I assume, since you say things are 
>working) looking POSIX-like.
>
>Personally, every time I see mention of someone using DOS paths in 
>Cygwin, or a Cygwin program, I wonder to myself why this works at all :-).

Could I get a gold star here?

Thanks for explaining things, mwoehlke.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Christopher Faylor]

On Mon, Jul 24, 2006 at 10:12:17AM -0700, Joachim Achtzehnter wrote:
>Christopher Faylor wrote:
>>On Fri, Jul 21, 2006 at 06:03:43PM -0700, Joachim Achtzehnter wrote:
>>>There was also some difference in newline handling which required
>>>another set of sed changes, arghh!
>>
>>Well with detailed bug reports like this and the previous "make
>>provides an error on one of my complex makefiles" we're surely well on
>>the road towards perfection.
>
>This sarcastic response to one sentence out of a much longer post
>quoted in isolation suggests that a clarification is in order.  Neither
>of my previous posts, not the one about the "threadlist_ix -1" error
>and not the one I wrote specifically in response to a claim that the
>recent changes to make were "not an inconvenience", were written with
>any expectations for a fix.

Well, you *could* expect a fix if you provided enough details.

It is pretty frustrating to see content-free bug reports like "there was
also some difference in newline handling" or "My big/complicated
makefile SEGVs".  Whether you intended these as bug reports or not, they
are still reports of problems and no package maintainer wants to see
reported problems sent to thousand of people whether they were just
intended to blow off steam or not.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Christopher Faylor]

On Mon, Jul 24, 2006 at 02:42:40PM -0400, Christopher Faylor wrote:
>On Mon, Jul 24, 2006 at 10:12:17AM -0700, Joachim Achtzehnter wrote:
>>Christopher Faylor wrote:
>>>On Fri, Jul 21, 2006 at 06:03:43PM -0700, Joachim Achtzehnter wrote:
>>>>There was also some difference in newline handling which required
>>>>another set of sed changes, arghh!
>>>
>>>Well with detailed bug reports like this and the previous "make
>>>provides an error on one of my complex makefiles" we're surely well on
>>>the road towards perfection.
>>
>>This sarcastic response to one sentence out of a much longer post
>>quoted in isolation suggests that a clarification is in order.  Neither
>>of my previous posts, not the one about the "threadlist_ix -1" error
>>and not the one I wrote specifically in response to a claim that the
>>recent changes to make were "not an inconvenience", were written with
>>any expectations for a fix.
>
>Well, you *could* expect a fix if you provided enough details.
>
>It is pretty frustrating to see content-free bug reports like "there was
>also some difference in newline handling" or "My big/complicated
>makefile SEGVs".  Whether you intended these as bug reports or not, they
>are still reports of problems and no package maintainer wants to see
>reported problems sent to thousand of people whether they were just
                                   s
>intended to blow off steam or not.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Joachim Achtzehnter]

Dave Korn wrote:

> Which begs the question: given that you were working on such a large and
> complex makefile system, and given that it had non-POSIX paths in a makefile,
> and given that it wasn't broke and didn't need fixing ...
> 
> ...  why on EARTH did you deliberately go and upgrade to a new version of make
> that doesn't support non-POSIX paths?

I did not. :-)

Things worked fine for me but a co-worker in another office location kept 
reporting that he can't build the system. After investigating tons of other 
possible reasons why his builds might be failing we eventually hit on the 
possibility that it might be due to differences in the Cygwin versions 
which the two of us would have installed independently at different times 
(in fact, he happened to re-install his PC a few times recently because of 
unrelated problems).

The fact that I didn't expect that the problems had anything to do with 
Cygwin shows how much trust people have in these tools. It also highlights 
the effect a small break with backwards compatibility can have for people 
because these things are expected to just work. This isn' just any 
application, it is the foundation on which everything rests.

Joachim


-- 
work:     joachima@netacquire.com   (http://www.netacquire.com)
private:  joachim@kraut.ca          (http://www.kraut.ca)

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Joachim Achtzehnter]

Christopher Faylor wrote:

> Well, you *could* expect a fix if you provided enough details.

Understood. The question is, can there still be value in reporting that a 
program crashes, even with minimal but potentially still useful 
information? I'm just asking and am genuinely interested in hearing the 
developers' preferences. My choice in this case ("threadlist_ix -1") was 
either to do nothing (for reasons not directly relevant to this discussion) 
or to post the information I had (the fact that it crashes and the 
associated error message). If this kind of less-than-ideal problem report 
is considered to be always useless, which would come as a surprise to me 
because as a developer I've seen many cases where a report like this is all 
that was needed to highlight the problem, then I won't post anything to 
this list in the future unless I have the resources to produce a complete, 
easily reproducible bug report.

> It is pretty frustrating to see content-free bug reports like "there
> was also some difference in newline handling"

Please don't take this out of context again, I already explained that this 
was an illustration of how breaking backward compatibility is inconvenient 
for users. I don't disagree in principle with decisions of this kind 
(treating newlines one way or another, accepting DOS paths or not), I only 
disagreed with the contention that *changing* such behaviour has no 
significant consequences ("no inconvenience"). I saw references related to 
newline treatment in the changelog and proceeded to apply fixes to my 
third-party makefiles (not written by me) without even thinking of 
mentioning this on the list, but it definitely was inconvenient, and when 
somebody claimed otherwise I felt I had to respond as I did.

> or "My big/complicated
> makefile SEGVs".  Whether you intended these as bug reports or not, they
> are still reports of problems and no package maintainer wants to see
> reported problems sent to thousand of people whether they were just
> intended to blow off steam or not.

As I explained at the top, this wasn't a matter of blowing off steam. It 
was a question of posting information which I had and considered 
potentially useful versus posting nothing and leaving you under the false 
impression that everything works. Given what has transpired, I guess I 
should have done the latter, or included a long disclaimer explaining why I 
posted it.

Thanks,

Joachim

-- 
work:     joachima@netacquire.com   (http://www.netacquire.com)
private:  joachim@kraut.ca          (http://www.kraut.ca)

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Christopher Faylor]

On Mon, Jul 24, 2006 at 12:53:19PM -0700, Joachim Achtzehnter wrote:
>Christopher Faylor wrote:
>>Well, you *could* expect a fix if you provided enough details.
>
>Understood.  The question is, can there still be value in reporting
>that a program crashes, even with minimal but potentially still useful
>information?  I'm just asking and am genuinely interested in hearing
>the developers' preferences.

No.  Reports of "XYZ dies when I run a complicated program" are
worthless unless the reporter is willing to help track down the problem.

>If this kind of less-than-ideal problem report is considered to be
>always useless, which would come as a surprise to me because as a
>developer I've seen many cases where a report like this is all that was
>needed to highlight the problem,

I would be very very surprised if you were able to fix problems when
someone just mentions that their program crashes when they do something
complicated.  If that really was the case then you would just have to
say that to yourself before every release in order to fix problems.

>>It is pretty frustrating to see content-free bug reports like "there
>>was also some difference in newline handling"
>
>Please don't take this out of context again, I already explained that this 
>was an illustration of how breaking backward compatibility is inconvenient 
>for users.

I didn't take it out of context before and I am not doing so now.  I
trimmed the parts that I wanted to respond to, as is good internet
etiquette.  I wasn't the person who mentioned inconvenience and had no
interest in responding to that.  I was trying to get to the bottom of
something that seemed like it could be a bug.

>I saw references related to newline treatment in the changelog and
>proceeded to apply fixes to my third-party makefiles (not written by
>me) without even thinking of mentioning this on the list, but it
>definitely was inconvenient, and when somebody claimed otherwise I felt
>I had to respond as I did.

Now I understand that you are referring to documented changes in the GNU
Make NEWS file.  So, this observation was directed towards the upstream
maintainer who wrote:

  * WARNING: Backward-incompatibility!
    In order to comply with POSIX, the way in which GNU make processes
    backslash-newline sequences in command strings has changed.  If your
    makefiles use backslash-newline sequences inside of single-quoted
    strings in command scripts you will be impacted by this change.  See
    the GNU make manual subsection "Splitting Command Lines" (node
    "Splitting Lines"), in section "Command Syntax", chapter "Writing the
    Commands in Rules", for details.

and your report has nothing to do with standard cygwin newline
complaints, as I assumed.

I guess that means there is nothing more to discuss.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Why are Windows paths broken in make 3.81?

[Valster Nico-anv009]

I think problem reports in itself are already useful so people can
search the mailing lists to see whether the type of problem they run
into is already reported. With some luck they can solve or workaround it
with the suggestions, but even if no solution or explanation is
available, it may save quite some effort while trying to figure out
whether the problem is just caused by yourself, e.g. by ignorance or
that other people ran into the same issue. (In this particular case,
someone could upgrade the Cygwin installation for a very different
reason and all of a sudden been bitten by the difference in make
behavior.)

> -----Original Message-----
> Sent: Monday, July 24, 2006 9:53 PM
> Christopher Faylor wrote:
> 
> > Well, you *could* expect a fix if you provided enough details.
> 
> Understood. The question is, can there still be value in reporting
that a
> program crashes, even with minimal but potentially still useful
> information? I'm just asking and am genuinely interested in hearing
the
> developers' preferences. My choice in this case ("threadlist_ix -1")
was
> either to do nothing (for reasons not directly relevant to this
> discussion)
> or to post the information I had (the fact that it crashes and the
> associated error message). If this kind of less-than-ideal problem
report
> is considered to be always useless, which would come as a surprise to
me
> because as a developer I've seen many cases where a report like this
is
> all
> that was needed to highlight the problem, then I won't post anything
to
> this list in the future unless I have the resources to produce a
complete,
> easily reproducible bug report.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Igor Peshansky]

On Mon, 24 Jul 2006, Christopher Faylor wrote:

> On Mon, Jul 24, 2006 at 01:01:55PM -0500, mwoehlke wrote:
> >Joachim Achtzehnter wrote:
> >>Christopher Faylor wrote:
> >>>On Fri, Jul 21, 2006 at 06:03:43PM -0700, Joachim Achtzehnter wrote:
> >>My second post was specifically in response to the claim by mwoehlke
> >>suggesting that the changes were "not an inconvenience". In this post
> >>all the issues I mentioned were intended as illustrations of such
> >>inconveniences, so there was even less implied expectation of somebody
> >>acting on these. Note, that I wrote that I had already addressed the
> >>issues caused by deliberate incompatibilities, all I intended to do was
> >>point out that it *had been* inconvenient.
> >
> >For the record, I was just trying to point out that the general
> >consensus around here seems to be 'don't use DOS paths in Cygwin', and
> >was using that to explain what I feel to be one major reason for the
> >change. I accept and acknowledge that this change may be inconvenient
> >for some people, but it is also my opinion that if you are affected by
> >it, you are doing something that was never condoned or officially
> >supported in the first place. (And, after all, WJM. ;-))
> >
> >I am glad you got things working and (I assume, since you say things are
> >working) looking POSIX-like.
> >
> >Personally, every time I see mention of someone using DOS paths in
> >Cygwin, or a Cygwin program, I wonder to myself why this works at all :-).
>
> Could I get a gold star here?

Absolutely.

> Thanks for explaining things, mwoehlke.

<http://cygwin.com/acronyms/#TITTTL> fodder: Why does this remind me of

	The Old Grey Donkey, Eeyore, stood by himself in a thistly corner
	of the forest, his front feet well apart, his head on one side,
	and thought about things.

? :-)
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Joachim Achtzehnter]

Christopher Faylor wrote:

> I guess that means there is nothing more to discuss.

Agreed, except for the following.

> On Mon, Jul 24, 2006 at 12:53:19PM -0700, Joachim Achtzehnter wrote:
>> Christopher Faylor wrote:
>>> Well, you *could* expect a fix if you provided enough details.
>> Understood.  The question is, can there still be value in reporting
>> that a program crashes, even with minimal but potentially still useful
>> information?  I'm just asking and am genuinely interested in hearing
>> the developers' preferences.
> 
> No.  Reports of "XYZ dies when I run a complicated program" are
> worthless unless the reporter is willing to help track down the problem.

I resent being mis-represented like this: The report mentioned a very 
specific error message and was about a change in behaviour from one version 
to the next. I accept your "No" answer though, you won't see similar 
reports from me in the future.

>> If this kind of less-than-ideal problem report is considered to be
>> always useless, which would come as a surprise to me because as a
>> developer I've seen many cases where a report like this is all that was
>> needed to highlight the problem,
> 
> I would be very very surprised if you were able to fix problems when
> someone just mentions that their program crashes when they do something
> complicated.  If that really was the case then you would just have to
> say that to yourself before every release in order to fix problems.

The point is that nobody was *just* mentioning what you write here. First 
off, as I wrote above, this was about changed behaviour between one version 
and the next, presumably implying that only a (relatively) small portion of 
the source code had changed. It was about the most recently released 
version, i.e. there is a good chance the changes are still (relatively) 
fresh in the minds of the developers. Thirdly, there was a specific error 
message rather than a totally uninformative crash, suggesting that it might 
(possibly) ring a bell. None of this implied that the information provided 
would be sufficient (and I didn't count on it), but from my experience 
there was a reasonable, if small, possibility that it might.

I've certainly seen many cases where I just needed to see an error message 
like this in conjunction with having released a recent change to know 
immediately what went wrong. Obviously, it is just as likely that this 
doesn't help at all. In spite of the latter, I definitely want to see such 
reports from our customers as it can save time for both of us. If the 
provided info doesn't help one can always ignore it until more effort is 
put into providing more details. In any case, the last thing I can afford 
to do in such a situation is to accost my customer, but then I'm in a 
different situation from you on that point. :-)

> If that really was the case then you would just have to
> say that to yourself before every release in order to fix problems.

And how do I divine the error message?

> I didn't take it out of context before and I am not doing so now.  I
> trimmed the parts that I wanted to respond to, as is good internet
> etiquette.

Trimming to the relevant parts is one thing, trimming (and rephrasing) to 
the point where the quote mis-represents what was written is another...

> I was trying to get to the bottom of something that seemed like it could
> be a bug.

If you hear more from me about the crash it will be with sufficient 
information to reproduce it without sending you several hundreds of 
thousands of lines of source code and makefiles.

Thanks,

Joachim

-- 
work:     joachima@netacquire.com   (http://www.netacquire.com)
private:  joachim@kraut.ca          (http://www.kraut.ca)

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Carlo Florendo]

Christopher Faylor wrote:

> I participate in cygwin because I like providing a linux-like interface
> on Windows.  

Booof!  This is the best reason why cygwin existed and why it still 
exists.  We hope this continues.

Best Regards,

Carlo
--
Carlo Florendo
Astra Philippines Inc.
www.astra.ph


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Chris Taylor]

Joachim Achtzehnter wrote:
> Christopher Faylor wrote:

>> I guess that means there is nothing more to discuss.

> Agreed, except for the following.

>> On Mon, Jul 24, 2006 at 12:53:19PM -0700, Joachim Achtzehnter wrote:
>>> Christopher Faylor wrote:
>>>> Well, you *could* expect a fix if you provided enough details.
>>> Understood.  The question is, can there still be value in reporting
>>> that a program crashes, even with minimal but potentially still useful
>>> information?  I'm just asking and am genuinely interested in hearing
>>> the developers' preferences.

>> No.  Reports of "XYZ dies when I run a complicated program" are
>> worthless unless the reporter is willing to help track down the problem.

> I resent being mis-represented like this: The report mentioned a very 
> specific error message and was about a change in behaviour from one 
> version to the next. I accept your "No" answer though, you won't see 
> similar reports from me in the future.

The problem was that you didn't follow the guidelines on:

Problem reports:       http://cygwin.com/problems.html

I don't recall seeing a cygcheck.out, and you certainly didn't break it 
down to a simple testcase..
This means that the maintainers (as well as the rest of us) have no real 
clue as to where to begin to replicate the behaviour so that they can 
bring their collective might to bear on it.


>>> If this kind of less-than-ideal problem report is considered to be
>>> always useless, which would come as a surprise to me because as a
>>> developer I've seen many cases where a report like this is all that was
>>> needed to highlight the problem,

>> I would be very very surprised if you were able to fix problems when
>> someone just mentions that their program crashes when they do something
>> complicated.  If that really was the case then you would just have to
>> say that to yourself before every release in order to fix problems.

> The point is that nobody was *just* mentioning what you write here. 
> First off, as I wrote above, this was about changed behaviour between 
> one version and the next, presumably implying that only a (relatively) 
> small portion of the source code had changed. It was about the most 
> recently released version, i.e. there is a good chance the changes are 
> still (relatively) fresh in the minds of the developers. Thirdly, there 
> was a specific error message rather than a totally uninformative crash, 
> suggesting that it might (possibly) ring a bell. None of this implied 
> that the information provided would be sufficient (and I didn't count on 
> it), but from my experience there was a reasonable, if small, 
> possibility that it might.

Even in cases where it might, what I've mentioned above applies, 
otherwise it's an incomplete bug-report that just clogs things up and 
makes it difficult to track down solutions..

> I've certainly seen many cases where I just needed to see an error 
> message like this in conjunction with having released a recent change to 
> know immediately what went wrong. Obviously, it is just as likely that 
> this doesn't help at all. In spite of the latter, I definitely want to 
> see such reports from our customers as it can save time for both of us. 
> If the provided info doesn't help one can always ignore it until more 
> effort is put into providing more details. In any case, the last thing I 
> can afford to do in such a situation is to accost my customer, but then 
> I'm in a different situation from you on that point. :-)

>> If that really was the case then you would just have to
>> say that to yourself before every release in order to fix problems.

> And how do I divine the error message?

Testcase, combined with gdb, perhaps?

>> I didn't take it out of context before and I am not doing so now.  I
>> trimmed the parts that I wanted to respond to, as is good internet
>> etiquette.

> Trimming to the relevant parts is one thing, trimming (and rephrasing) 
> to the point where the quote mis-represents what was written is another...

>> I was trying to get to the bottom of something that seemed like it could
>> be a bug.

> If you hear more from me about the crash it will be with sufficient 
> information to reproduce it without sending you several hundreds of 
> thousands of lines of source code and makefiles.

> Thanks,

> Joachim


Anyway.... Hopefully things are about done with that now..

EqUaTe

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Michael Hirsch]

On 7/21/06, mwoehlke <mwoehlke@tibco.com> wrote:
> Michael Hirsch wrote:
> > Here is a sample Makefile that breaks with Gnu Make 3.81-1 under
> > Cygwin, but works fine with Gnu Make 3.80-1.  We have been writing
> > these types of Makefiles for years, using both Windows and Cygwin
> > tools, and this is the first time Make has ever broken like this.
> >
> > I see in another thread that this is a known issue, though I don't see
> > it in the changelogs for make 3.81.
> >
> > Was this a deliberate break with backwards compatibility?  It means
> > that every single reference to a windows path needs to be wrapped in
> > cygpath, which is a huge inconvenience.
>
> Yes. See <http://cygwin.com/ml/cygwin-announce/2006-07/msg00008.html>.
> If you are using a POSIX-like "OS" (i.e. Cygwin), you should be using
> POSIX paths. That's not an inconvenience, that's called writing a bad
> makefile. If you aren't using Cygwin for the POSIX environment, you
> should be using MinGW.

I see.  Unfortunately, I am trying to use cygwin to make my life
easier on Windows, but I am still constrained to use windows programs.
 Many of them cannot use the cygwin paths, but require a path like
"c:/my/path.exe".  It will be very difficult to switch back and forth
between path representations.  I guess I do need to look into MinGW.

> > Is it broken only on Windows?
>
> That sounds like a silly question... 'are Windows paths only broken on
> Windows?'

It sounds like a silly question, but it isn't.  I tested, and yes, if
you have a directory named "c:" in Linux, make is broken on that
directory, too.  Since "c:" is a valid name in Linux (and POSIX, I
believe) I consider that a bug in make.  I'll have to report that to
GNU, as it is not a cygwin issue.  The error message on Linux is just
as incomprehensible as it is Cygwin, too, so at least I know who to
talk to about it.

> > Is this a cywin only bug?  What possible reason could there be to
> > introduce this deliberately?
>
> No, as it is not a "bug". However it is specific to Cygwin. See the
> aforementioned announcement. CGF would have to speak to "why" (and I
> would appreciate if he would, just because I am curious :-)), but I
> would guess it is to "encourage" people to use correct (i.e. POSIX) paths.

I guess that was the reason.  How disappointing.  I always thought
that cygwin provided a great service by allowing me to use both
windows and posix paths.  I'll miss that capability a lot.

Michael

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Christopher Faylor]

On Wed, Jul 26, 2006 at 10:12:51AM -0600, Michael Hirsch wrote:
>>Yes. See <http://cygwin.com/ml/cygwin-announce/2006-07/msg00008.html>.
>>If you are using a POSIX-like "OS" (i.e. Cygwin), you should be using
>>POSIX paths. That's not an inconvenience, that's called writing a bad
>>makefile. If you aren't using Cygwin for the POSIX environment, you
>>should be using MinGW.
>
>I see.  Unfortunately, I am trying to use cygwin to make my life
>easier on Windows, but I am still constrained to use windows programs.
>Many of them cannot use the cygwin paths, but require a path like
>"c:/my/path.exe".  It will be very difficult to switch back and forth
>between path representations.  I guess I do need to look into MinGW.

Maybe someone here would be willing to post a sed transformation which
would change c:\some\dos\path to /cygdrive/c/some/dos/path.

>>> Is it broken only on Windows?
>>
>>That sounds like a silly question... 'are Windows paths only broken on
>>Windows?'
>
>It sounds like a silly question, but it isn't.  I tested, and yes, if
>you have a directory named "c:" in Linux, make is broken on that
>directory, too.  Since "c:" is a valid name in Linux (and POSIX, I
>believe) I consider that a bug in make.  I'll have to report that to
>GNU, as it is not a cygwin issue.  The error message on Linux is just
>as incomprehensible as it is Cygwin, too, so at least I know who to
>talk to about it.

I don't think there is a make on any non-windows OS which will deal well
with filenames that contain colons.  However, you might have better luck
if you quote the colon with a '\'.

>>No, as it is not a "bug". However it is specific to Cygwin. See the
>>aforementioned announcement. CGF would have to speak to "why" (and I
>>would appreciate if he would, just because I am curious :-)), but I
>>would guess it is to "encourage" people to use correct (i.e. POSIX) paths.
>
>I guess that was the reason.  How disappointing.  I always thought
>that cygwin provided a great service by allowing me to use both
>windows and posix paths.  I'll miss that capability a lot.

You are not helpless here.  You can keep using the old version of make.
You can try to adapt the patches to the new version of make and use
that yourself.  This is free software.  You don't have to rely on what
the "vendor" is supplying you.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Christopher Faylor]

On Wed, Jul 26, 2006 at 12:26:09PM -0400, Christopher Faylor wrote:
>Maybe someone here would be willing to post a sed transformation which
>would change c:\some\dos\path to /cygdrive/c/some/dos/path.

Here are two simple, imperfect proof-of-concept perl scripts.

The first one just translates everything to /cygdrive/X/foo.  The second
one uses cygpath to get mount-table-aware paths.

And, to reiterate: I know that these aren't perfect and miss some cases
(like when part of a filename is located in a variable).  I merely offer
them as is as an example of what could be done.

cgf

#!/usr/bin/perl
while (<>) {
    s!\b([a-z]):((?:[/\\][^/\\\s]+)+)!"/cygdrive/$1" . &fixslash($2)!eg;
    print;
}

sub fixslash {
    my $x = shift;
    $x =~ s%\\%/%g;
    return $x;
}

#!/usr/bin/perl
while (<>) {
    s!\b([a-z]:(?:[/\\][^/\\\s]+)+)!&fix($1)!eg;
    print;
}

sub fix {
    my $x = `cygpath -u '$_[0]'`;
    chomp $x;
    return $x;
}

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Igor Peshansky]

On Wed, 26 Jul 2006, Michael Hirsch wrote:

> On 7/21/06, mwoehlke <mwoehlke@XXXXX.XXX> wrote:

<http://cygwin.com/acronyms/#PCYMTNQREAIYR>.  Thanks.

> > Michael Hirsch wrote:
> > [snip]
> > > Is it broken only on Windows?
> >
> > That sounds like a silly question... 'are Windows paths only broken on
> > Windows?'
>
> It sounds like a silly question, but it isn't.  I tested, and yes, if
> you have a directory named "c:" in Linux, make is broken on that
> directory, too.  Since "c:" is a valid name in Linux (and POSIX, I
> believe) I consider that a bug in make.  I'll have to report that to
> GNU, as it is not a cygwin issue.  The error message on Linux is just
> as incomprehensible as it is Cygwin, too, so at least I know who to
> talk to about it.

While ':' is a valid filename character on Linux (though not on all
filesystems, obviously), it is a special character in make.  So you need
to be careful when using it in Makefiles.  Just like '>' is a valid
filename character, but you would not expect to be able to use it unquoted
in your shell.

> > > Is this a cywin only bug?  What possible reason could there be to
> > > introduce this deliberately?
> >
> > No, as it is not a "bug". However it is specific to Cygwin. See the
> > aforementioned announcement. CGF would have to speak to "why" (and I
> > would appreciate if he would, just because I am curious :-)), but I
> > would guess it is to "encourage" people to use correct (i.e. POSIX)
> > paths.
>
> I guess that was the reason.  How disappointing.  I always thought
> that cygwin provided a great service by allowing me to use both
> windows and posix paths.  I'll miss that capability a lot.

I don't think any of the Cygwin package maintainers would deliberately
break existing functionality for some purist reasons.  Besides, there's no
need to guess.  CGF already stated the reason: maintaining a
Cygwin-specific patch to support this functionality has become too
cumbersome, and CGF decided that his volunteer effort is better spent
doing other, more important things for Cygwin.

HTH,
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Igor Peshansky]

On Wed, 26 Jul 2006, Christopher Faylor wrote:

> On Wed, Jul 26, 2006 at 10:12:51AM -0600, Michael Hirsch wrote:
> >>Yes. See <http://cygwin.com/ml/cygwin-announce/2006-07/msg00008.html>.
> >>If you are using a POSIX-like "OS" (i.e. Cygwin), you should be using
> >>POSIX paths. That's not an inconvenience, that's called writing a bad
> >>makefile. If you aren't using Cygwin for the POSIX environment, you
> >>should be using MinGW.
> >
> >I see.  Unfortunately, I am trying to use cygwin to make my life
> >easier on Windows, but I am still constrained to use windows programs.
> >Many of them cannot use the cygwin paths, but require a path like
> >"c:/my/path.exe".  It will be very difficult to switch back and forth
> >between path representations.  I guess I do need to look into MinGW.
>
> Maybe someone here would be willing to post a sed transformation which
> would change c:\some\dos\path to /cygdrive/c/some/dos/path.

Here you go:

sed -e 's/\\/\\\\/g;s/^/cygpath /;e'

HTH.  ;-)
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Why are Windows paths broken in make 3.81?

[William Sheehan]

I have been following this discussion closely, as we were also hit by this
change.  However, in all the emails and the ChangeLog, I still can't find an
official reason why the change was made in the first place.  Was it for
technical reasons?  And if so, would the Cygwin team accept a patch that
readded win32 path support?  Or was it for idealistic reasons?

Thanks for any replies; I am genuinely curious about the official reason.

William Sheehan
Builds Engineer / Network Administrator
Open Interface North America



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Why are Windows paths broken in make 3.81?

[Igor Peshansky]

On Wed, 26 Jul 2006, William Sheehan wrote:

> I have been following this discussion closely, as we were also hit by
> this change.  However, in all the emails and the ChangeLog, I still
> can't find an official reason why the change was made in the first
> place.  Was it for technical reasons?  And if so, would the Cygwin team
> accept a patch that readded win32 path support?  Or was it for
> idealistic reasons?
>
> Thanks for any replies; I am genuinely curious about the official
> reason.

The official reason, as stated by the maintainer, was that he was tired of
maintaining an out-of-tree patch (which is also why it doesn't appear in
the official upstream ChangeLog).  It's not Cygwin that needs to be
patched, it's make.  Try making the above pitch to the make maintainers
(on the GNU make list or through Savannah -- see
<http://gnu.org/software/make/>).  If the vanilla make sources start
supporting Win32 paths in Cygwin, with someone else providing and
maintaining this functionality upstream, I'm sure the Cygwin make package
maintainer will not go out of his way to remove this support.

HTH,
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[mwoehlke]

Michael Hirsch wrote:
> On 7/21/06, mwoehlke <mwoehlke@tibco.com> wrote:
>> Michael Hirsch wrote:
>> > Here is a sample Makefile that breaks with Gnu Make 3.81-1 under
>> > Cygwin, but works fine with Gnu Make 3.80-1.  We have been writing
>> > these types of Makefiles for years, using both Windows and Cygwin
>> > tools, and this is the first time Make has ever broken like this.
>> >
>> > I see in another thread that this is a known issue, though I don't see
>> > it in the changelogs for make 3.81.
>> >
>> > Was this a deliberate break with backwards compatibility?  It means
>> > that every single reference to a windows path needs to be wrapped in
>> > cygpath, which is a huge inconvenience.
>>
>> Yes. See <http://cygwin.com/ml/cygwin-announce/2006-07/msg00008.html>.
>> If you are using a POSIX-like "OS" (i.e. Cygwin), you should be using
>> POSIX paths. That's not an inconvenience, that's called writing a bad
>> makefile. If you aren't using Cygwin for the POSIX environment, you
>> should be using MinGW.
> 
> I see.  Unfortunately, I am trying to use cygwin to make my life
> easier on Windows, but I am still constrained to use windows programs.
> Many of them cannot use the cygwin paths, but require a path like
> "c:/my/path.exe".  It will be very difficult to switch back and forth
> between path representations.  I guess I do need to look into MinGW.

Ah, that problem. There are two possible solutions. One is to write a 
wrapper script for your Windows programs that will take the args, 
translate them (using cygpath), and then invoke the actual program. The 
other is to use 'cygpath' directly in your makefile, as needed.

I also use Cygwin to drive the Microsoft compilers, having switched 
recently from an MKS environment. I used both of the above techniques. 
My GNUmakefile's do not contain Windows paths, as they should not in a 
Cygwin environment.

>> > Is it broken only on Windows?
>>
>> That sounds like a silly question... 'are Windows paths only broken on
>> Windows?'
> 
> It sounds like a silly question, but it isn't.  I tested, and yes, if
> you have a directory named "c:" in Linux, make is broken on that
> directory, too.  Since "c:" is a valid name in Linux (and POSIX, I
> believe) I consider that a bug in make.  I'll have to report that to
> GNU, as it is not a cygwin issue.  The error message on Linux is just
> as incomprehensible as it is Cygwin, too, so at least I know who to
> talk to about it.

Right, that would be something to take up with the make author. However, 
as both CGF and Igor mentioned, ':' means something special to make, and 
so probably needs to be quoted/escaped/something. There is probably a 
way to do this that works right now on make 3.81.

-- 
Matthew
Ok, so the quotes aren't entirely original.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Why are Windows paths broken in make 3.81?

[Christopher Faylor]

On Thu, Jul 27, 2006 at 02:00:41PM -0500, mwoehlke wrote:
>Michael Hirsch wrote:
>>I see.  Unfortunately, I am trying to use cygwin to make my life
>>easier on Windows, but I am still constrained to use windows programs.
>>Many of them cannot use the cygwin paths, but require a path like
>>"c:/my/path.exe".  It will be very difficult to switch back and forth
>>between path representations.  I guess I do need to look into MinGW.
>
>Ah, that problem. There are two possible solutions. One is to write a 
>wrapper script for your Windows programs that will take the args, 
>translate them (using cygpath), and then invoke the actual program. The 
>other is to use 'cygpath' directly in your makefile, as needed.

One of the (so far unremarked upon) perl programs that I sent earlier
should work fairly well for translating paths.

>>It sounds like a silly question, but it isn't.  I tested, and yes, if
>>you have a directory named "c:" in Linux, make is broken on that
>>directory, too.  Since "c:" is a valid name in Linux (and POSIX, I
>>believe) I consider that a bug in make.  I'll have to report that to
>>GNU, as it is not a cygwin issue.  The error message on Linux is just
>>as incomprehensible as it is Cygwin, too, so at least I know who to
>>talk to about it.
>
>Right, that would be something to take up with the make author.
>However, as both CGF and Igor mentioned, ':' means something special to
>make, and so probably needs to be quoted/escaped/something.  There is
>probably a way to do this that works right now on make 3.81.

You have to quote the : with a backslash.  Inability to handle unquoted
colons is definitely not a bug in make.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Why are Windows paths broken in make 3.81?

[Jörg Schaible]

Christopher Faylor wrote on Wednesday, July 26, 2006 6:26 PM:

> On Wed, Jul 26, 2006 at 10:12:51AM -0600, Michael Hirsch wrote:
>>> Yes. See
> <http://cygwin.com/ml/cygwin-announce/2006-07/msg00008.html>.
>>> If you are using a POSIX-like "OS" (i.e. Cygwin), you should be
>>> using POSIX paths. That's not an inconvenience, that's called
>>> writing a bad makefile. If you aren't using Cygwin for the POSIX
>>> environment, you should be using MinGW.
>> 
>> I see.  Unfortunately, I am trying to use cygwin to make my life
>> easier on Windows, but I am still constrained to use windows
>> programs. Many of them cannot use the cygwin paths, but require a
>> path like "c:/my/path.exe".  It will be very difficult to switch
>> back and forth between path representations.  I guess I do need to
>> look into MinGW. 
> 
> Maybe someone here would be willing to post a sed transformation which
> would change c:\some\dos\path to /cygdrive/c/some/dos/path.

I already send a pointer in this thread to a mail I sent some years ago. The make functions aare still valid and makes paths transparent for make files working on Cygwin or otgher Unix environments.

[snip]

- Jörg

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Why are Windows paths broken in make 3.81?

[Jörg Schaible]

Larry Hall (Cygwin) wrote on Sunday, July 23, 2006 1:08 AM:

> On 07/21/2006, Joachim Achtzehnter wrote:
>> I just had to deal with such a messy system and the new Cygwin make
>> doesn't work. Even though this collection of makefiles was initially
>> written on a POSIX system it still got into trouble with DOS paths
>> because some of the tools it calls to generate makefiles return
>> platform-specific paths. So this works fine on a POSIX system,
>> worked fine on Win2000 with the old make, but now I had to
>> understand complicated sed programs to add extra platform-specific
>> sed transformations to convert paths returned by other
>> cross-platform tools to something the new make accepts. 
>> 
> 
> 
> Did you think about using 'cygpath' on the result instead of adding
> extra platform specific transformations to your complicated sed
> programs? 

Some useful definitions I've posted some years ago:
http://www.cygwin.com/ml/cygwin/2000-06/msg01318.html

:)

- Jörg

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/