Re: May g++ output windows-style paths instead of cygwin-style one?
On Tue, 16 Aug 2005, Angel Tsankov wrote: - Original Message - From: Angel Tsankov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 12:11 PM Subject: Re: May g++ output windows-style paths instead of cygwin-style one? - Original Message - From: Brian Dessent [EMAIL PROTECTED] To: cygwin mailing list [EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 12:00 PM Subject: Re: May g++ output windows-style paths instead of cygwin-style one? http://cygwin.com/acronyms/#PCYMTNQREAIYR. Let's not feed the spammers. Thanks. Incidentally, what kind of mailer quotes full headers like this? Angel Tsankov wrote: I have this problem, 'cause I use a windows build of make 3.81beta3 and it does not recognize cygwin style paths. The latest cygwin build of make is 3.80, which has some bugs, and I cannot use it. I think it would be more productive for you to get Cygwin make working than to try to jerry-rig a windows make into a posix environment. If you are running into a specific bug in the current packaged version that is fixed upstream, then you should document it here and the Cygwin package maintainer might release an updated package. Well, how do I document the bug? OK, here's something like a test case. Since a couple of my previous attempts to post a reply with a zip file attachment were unsuccessful, I've put the test case here: http://debian.fmi.uni-sofia.bg/~angel/test_case_make_3.80.zip To summarize, for those who'd rather not download the full zip: BEGIN makefile GetAllFiles = \ $(eval AllFiles := $(wildcard $(addsuffix /*,$(strip $(1) \ $(AllFiles) \ $(if $(strip $(AllFiles)),$(call GetAllFiles,$(AllFiles))) AllFiles := $(call GetAllFiles,Source) all: @echo $(AllFiles) - END makefile - The Source directory contains 2 files, File1.h and File2.h. The result I get when running (the cygwin version of) make on my system is: Source/File1.h Source/File2.h h And the expected result is: Source/File1.h Source/File2.h There are a bunch of things wrong with the code above (in particular, the variable AllFiles is overridden), but it does look like a genuine make bug (in the expansion of a $(call) function). Could you point out other wrong things with the code above so that I try to avoid them in the future? Regards, Angel Tsankov [EMAIL PROTECTED] -- 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: May g++ output windows-style paths instead of cygwin-style one?
- Original Message - From: Igor Pechtchanski [EMAIL PROTECTED] To: Angel Tsankov [EMAIL PROTECTED] Cc: cygwin@cygwin.com Sent: Thursday, August 18, 2005 6:05 PM Subject: Re: May g++ output windows-style paths instead of cygwin-style one? On Thu, 18 Aug 2005, Angel Tsankov wrote: On Tue, 16 Aug 2005, Angel Tsankov wrote: - Original Message - From: Angel Tsankov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 12:11 PM Subject: Re: May g++ output windows-style paths instead of cygwin-style one? - Original Message - From: Brian Dessent [EMAIL PROTECTED] To: cygwin mailing list [EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 12:00 PM Subject: Re: May g++ output windows-style paths instead of cygwin-style one? http://cygwin.com/acronyms/#PCYMTNQREAIYR. Let's not feed the spammers. Thanks. Incidentally, what kind of mailer quotes full headers like this? Angel Tsankov wrote: I have this problem, 'cause I use a windows build of make 3.81beta3 and it does not recognize cygwin style paths. The latest cygwin build of make is 3.80, which has some bugs, and I cannot use it. I think it would be more productive for you to get Cygwin make working than to try to jerry-rig a windows make into a posix environment. If you are running into a specific bug in the current packaged version that is fixed upstream, then you should document it here and the Cygwin package maintainer might release an updated package. Well, how do I document the bug? OK, here's something like a test case. Since a couple of my previous attempts to post a reply with a zip file attachment were unsuccessful, I've put the test case here: http://debian.fmi.uni-sofia.bg/~angel/test_case_make_3.80.zip To summarize, for those who'd rather not download the full zip: BEGIN makefile GetAllFiles = \ $(eval AllFiles := $(wildcard $(addsuffix /*,$(strip $(1) \ $(AllFiles) \ $(if $(strip $(AllFiles)),$(call GetAllFiles,$(AllFiles))) AllFiles := $(call GetAllFiles,Source) all: @echo $(AllFiles) - END makefile - The Source directory contains 2 files, File1.h and File2.h. The result I get when running (the cygwin version of) make on my system is: Source/File1.h Source/File2.h h And the expected result is: Source/File1.h Source/File2.h There are a bunch of things wrong with the code above (in particular, the variable AllFiles is overridden), but it does look like a genuine make bug (in the expansion of a $(call) function). Could you point out other wrong things with the code above so that I try to avoid them in the future? Well, it's not as bad as it sounded -- it's a rather small bunch, actually. :-) As I understand it, you're trying to implement a recursive directory search (akin to Ant's ** wildcard). Try as I might, I couldn't come up with a clearer way of doing this, so I guess what you have is ok. My only gripe is that the AllFiles variable is going to be clobbered, so if you have GetAllFiles = \ $(eval AllFiles := $(wildcard $(addsuffix /*,$(strip $(1) \ $(AllFiles) \ $(if $(strip $(AllFiles)),$(call GetAllFiles,$(AllFiles))) AllFiles := $(call GetAllFiles,Source) AllOtherFiles := $(call GetAllFiles,Includes) You will be surprised afterwards when looking at the value of $(AllFiles)... You could rewrite it as GetAllFiles = \ $(eval $(0)_123 := $(wildcard $(addsuffix /*,$(strip $(1) \ $($(0)_123) \ $(if $(strip $($(0)_123)),$(call GetAllFiles,$($(0)_123))) to avoid name clashes... BTW, the workaround I proposed (i.e., $(call GetAllFiles,Source makefile)) doesn't always work. Unfortunately, you are right. I decided to use recursively expanded variables till next release despite my striving for efficiency. I think you may just have to find the right number of extra spaces in variable assignments... Well, I could not find that number - it seemed to depend on the number of file names in the list and I did not investigate it any further so I'm not quite sure if this exactly was the case. -- 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: May g++ output windows-style paths instead of cygwin-style one?
On Thu, 18 Aug 2005, Angel Tsankov wrote: - Original Message - From: Igor Pechtchanski [EMAIL PROTECTED] To: Angel Tsankov [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Umm, again, http://cygwin.com/acronyms/#PCYMTNQREAIYR... On Thu, 18 Aug 2005, Angel Tsankov wrote: On Tue, 16 Aug 2005, Angel Tsankov wrote: - Original Message - From: Angel Tsankov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 12:11 PM Subject: Re: May g++ output windows-style paths instead of cygwin-style one? - Original Message - From: Brian Dessent [EMAIL PROTECTED] To: cygwin mailing list [EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 12:00 PM Subject: Re: May g++ output windows-style paths instead of cygwin-style one? http://cygwin.com/acronyms/#PCYMTNQREAIYR. Let's not feed the spammers. Thanks. Incidentally, what kind of mailer quotes full headers like this? Angel Tsankov wrote: I have this problem, 'cause I use a windows build of make 3.81beta3 and it does not recognize cygwin style paths. The latest cygwin build of make is 3.80, which has some bugs, and I cannot use it. I think it would be more productive for you to get Cygwin make working than to try to jerry-rig a windows make into a posix environment. If you are running into a specific bug in the current packaged version that is fixed upstream, then you should document it here and the Cygwin package maintainer might release an updated package. Well, how do I document the bug? OK, here's something like a test case. Since a couple of my previous attempts to post a reply with a zip file attachment were unsuccessful, I've put the test case here: http://debian.fmi.uni-sofia.bg/~angel/test_case_make_3.80.zip To summarize, for those who'd rather not download the full zip: BEGIN makefile GetAllFiles = \ $(eval AllFiles := $(wildcard $(addsuffix /*,$(strip $(1) \ $(AllFiles) \ $(if $(strip $(AllFiles)),$(call GetAllFiles,$(AllFiles))) AllFiles := $(call GetAllFiles,Source) all: @echo $(AllFiles) - END makefile - The Source directory contains 2 files, File1.h and File2.h. The result I get when running (the cygwin version of) make on my system is: Source/File1.h Source/File2.h h And the expected result is: Source/File1.h Source/File2.h There are a bunch of things wrong with the code above (in particular, the variable AllFiles is overridden), but it does look like a genuine make bug (in the expansion of a $(call) function). Could you point out other wrong things with the code above so that I try to avoid them in the future? Well, it's not as bad as it sounded -- it's a rather small bunch, actually. :-) As I understand it, you're trying to implement a recursive directory search (akin to Ant's ** wildcard). Try as I might, I couldn't come up with a clearer way of doing this, so I guess what you have is ok. My only gripe is that the AllFiles variable is going to be clobbered, so if you have GetAllFiles = \ $(eval AllFiles := $(wildcard $(addsuffix /*,$(strip $(1) \ $(AllFiles) \ $(if $(strip $(AllFiles)),$(call GetAllFiles,$(AllFiles))) AllFiles := $(call GetAllFiles,Source) AllOtherFiles := $(call GetAllFiles,Includes) You will be surprised afterwards when looking at the value of $(AllFiles)... You could rewrite it as GetAllFiles = \ $(eval $(0)_123 := $(wildcard $(addsuffix /*,$(strip $(1) \ $($(0)_123) \ $(if $(strip $($(0)_123)),$(call GetAllFiles,$($(0)_123))) to avoid name clashes... BTW, the workaround I proposed (i.e., $(call GetAllFiles,Source makefile)) doesn't always work. Unfortunately, you are right. I decided to use recursively expanded variables till next release despite my striving for efficiency. I think you may just have to find the right number of extra spaces in variable assignments... Well, I could not find that number - it seemed to depend on the number of file names in the list and I did not investigate it any further so I'm not quite sure if this exactly was the case. Another thing you could try is run the final result of $(call GetAllFiles,...) through $(wildcard ...) -- all non-existent files will be eliminated. Inefficient, I know, but safe. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire
May g++ output windows-style paths instead of cygwin-style one?
Is there any way I can force the cygwin build of g++ to output folders using windows style (e.g. c:\folder\file) instead of cygwin style (/cygdrive/c/folder/file) when writing dependency files (-MM option)? I have this problem, 'cause I use a windows build of make 3.81beta3 and it does not recognize cygwin style paths. The latest cygwin build of make is 3.80, which has some bugs, and I cannot use it. Angel Tsankov [EMAIL PROTECTED] -- 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: May g++ output windows-style paths instead of cygwin-style one?
Angel Tsankov wrote: Is there any way I can force the cygwin build of g++ to output folders using windows style (e.g. c:\folder\file) instead of cygwin style (/cygdrive/c/folder/file) when writing dependency files (-MM option)? No, there's no way to do that. You could probably come up with a perl command that would filter the files through cygpath to convert the paths, though. I have this problem, 'cause I use a windows build of make 3.81beta3 and it does not recognize cygwin style paths. The latest cygwin build of make is 3.80, which has some bugs, and I cannot use it. I think it would be more productive for you to get Cygwin make working than to try to jerry-rig a windows make into a posix environment. If you are running into a specific bug in the current packaged version that is fixed upstream, then you should document it here and the Cygwin package maintainer might release an updated package. Brian -- 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: May g++ output windows-style paths instead of cygwin-style one?
- Original Message - From: Brian Dessent [EMAIL PROTECTED] To: cygwin mailing list cygwin@cygwin.com Sent: Tuesday, August 16, 2005 12:00 PM Subject: Re: May g++ output windows-style paths instead of cygwin-style one? Angel Tsankov wrote: Is there any way I can force the cygwin build of g++ to output folders using windows style (e.g. c:\folder\file) instead of cygwin style (/cygdrive/c/folder/file) when writing dependency files (-MM option)? No, there's no way to do that. You could probably come up with a perl command that would filter the files through cygpath to convert the paths, though. I have this problem, 'cause I use a windows build of make 3.81beta3 and it does not recognize cygwin style paths. The latest cygwin build of make is 3.80, which has some bugs, and I cannot use it. I think it would be more productive for you to get Cygwin make working than to try to jerry-rig a windows make into a posix environment. If you are running into a specific bug in the current packaged version that is fixed upstream, then you should document it here and the Cygwin package maintainer might release an updated package. Well, how do I document the bug? Angel Tsankov [EMAIL PROTECTED] Brian -- 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/ -- 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: May g++ output windows-style paths instead of cygwin-style one?
Angel Tsankov wrote: Well, how do I document the bug? Start here: Problem reports: http://cygwin.com/problems.html Post a concise explanation of what happens, what was expected to happen, and what did not happen. Include a simple testcase if possible. Brian -- 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: May g++ output windows-style paths instead of cygwin-style one?
- Original Message - From: Angel Tsankov [EMAIL PROTECTED] To: cygwin@cygwin.com Sent: Tuesday, August 16, 2005 12:11 PM Subject: Re: May g++ output windows-style paths instead of cygwin-style one? - Original Message - From: Brian Dessent [EMAIL PROTECTED] To: cygwin mailing list cygwin@cygwin.com Sent: Tuesday, August 16, 2005 12:00 PM Subject: Re: May g++ output windows-style paths instead of cygwin-style one? Angel Tsankov wrote: Is there any way I can force the cygwin build of g++ to output folders using windows style (e.g. c:\folder\file) instead of cygwin style (/cygdrive/c/folder/file) when writing dependency files (-MM option)? No, there's no way to do that. You could probably come up with a perl command that would filter the files through cygpath to convert the paths, though. I have this problem, 'cause I use a windows build of make 3.81beta3 and it does not recognize cygwin style paths. The latest cygwin build of make is 3.80, which has some bugs, and I cannot use it. I think it would be more productive for you to get Cygwin make working than to try to jerry-rig a windows make into a posix environment. If you are running into a specific bug in the current packaged version that is fixed upstream, then you should document it here and the Cygwin package maintainer might release an updated package. Well, how do I document the bug? OK, here's something like a test case. Since a couple of my previous attempts to post a reply with a zip file attachment were unsuccessful, I've put the test case here: http://debian.fmi.uni-sofia.bg/~angel/test_case_make_3.80.zip The result I get when running (the cygwin version of) make on my system is: Source/File1.h Source/File2.h h And the expected result is: Source/File1.h Source/File2.h Result of running 'make --version': GNU Make 3.80 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. It is a very strange problem. A couple of weeks ago I started a thread about the exact same problem on the make-w32 mailing list, assuming it had something to do with long file names. The thread is located here: http://lists.gnu.org/archive/html/make-w32/2005-07/msg00011.html As one can see, this problem has been fixed. Unfortunately, no newer version of make has been release so far, except for betas, the latest one being is 3.81beta3. The source code of the windows version of 3.81beta3 is available at ftp://alpha.gnu.org/gnu/make/ HTH Angel Tsankov [EMAIL PROTECTED] -- 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: May g++ output windows-style paths instead of cygwin-style one?
On Tue, 16 Aug 2005, Angel Tsankov wrote: - Original Message - From: Angel Tsankov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 12:11 PM Subject: Re: May g++ output windows-style paths instead of cygwin-style one? - Original Message - From: Brian Dessent [EMAIL PROTECTED] To: cygwin mailing list [EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 12:00 PM Subject: Re: May g++ output windows-style paths instead of cygwin-style one? http://cygwin.com/acronyms/#PCYMTNQREAIYR. Let's not feed the spammers. Thanks. Incidentally, what kind of mailer quotes full headers like this? Angel Tsankov wrote: I have this problem, 'cause I use a windows build of make 3.81beta3 and it does not recognize cygwin style paths. The latest cygwin build of make is 3.80, which has some bugs, and I cannot use it. I think it would be more productive for you to get Cygwin make working than to try to jerry-rig a windows make into a posix environment. If you are running into a specific bug in the current packaged version that is fixed upstream, then you should document it here and the Cygwin package maintainer might release an updated package. Well, how do I document the bug? OK, here's something like a test case. Since a couple of my previous attempts to post a reply with a zip file attachment were unsuccessful, I've put the test case here: http://debian.fmi.uni-sofia.bg/~angel/test_case_make_3.80.zip To summarize, for those who'd rather not download the full zip: BEGIN makefile GetAllFiles = \ $(eval AllFiles := $(wildcard $(addsuffix /*,$(strip $(1) \ $(AllFiles) \ $(if $(strip $(AllFiles)),$(call GetAllFiles,$(AllFiles))) AllFiles := $(call GetAllFiles,Source) all: @echo $(AllFiles) - END makefile - The Source directory contains 2 files, File1.h and File2.h. The result I get when running (the cygwin version of) make on my system is: Source/File1.h Source/File2.h h And the expected result is: Source/File1.h Source/File2.h There are a bunch of things wrong with the code above (in particular, the variable AllFiles is overridden), but it does look like a genuine make bug (in the expansion of a $(call) function). Adding some trace commands shows that the function invocation itself produces the right result, and the corruption happens on variable assignment (affected by the number of whitespace in the assignment line). Simply invoking @echo $(call GetAllFiles,Source) as part of the all target produces the right result. As a temporary workaround, invoke GetAllFiles like this: AllFiles := $(call GetAllFiles,Source makefile) Using recursively expanded variables, e.g., AllFiles = $(call GetAllFiles,Source) , also fixes the problem, but they aren't really a good solution for this. Result of running 'make --version': GNU Make 3.80 [snip] It is a very strange problem. Indeed. A couple of weeks ago I started a thread about the exact same problem on the make-w32 mailing list, assuming it had something to do with long file names. The thread is located here: http://lists.gnu.org/archive/html/make-w32/2005-07/msg00011.html Not the same problem. There, the output was corrupted, here, the variable assignment has gone awry. As one can see, this problem has been fixed. Unfortunately, no newer version of make has been release so far, except for betas, the latest one being is 3.81beta3. The source code of the windows version of 3.81beta3 is available at ftp://alpha.gnu.org/gnu/make/ This particular problem must've been fixed by some other patch. Nonetheless, now that the make maintainer is aware that there is a bug, he'll likely look into releasing the updated version of make at some point. Since he's a volunteer (like the rest of us), he'll do it on his own schedule (the bug is relatively minor, and there's a workaround, so this probably won't happen soon). HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA -- 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: May g++ output windows-style paths instead of cygwin-style one?
On Tue, Aug 16, 2005 at 10:29:17AM -0400, Igor Pechtchanski wrote: This particular problem must've been fixed by some other patch. Nonetheless, now that the make maintainer is aware that there is a bug, he'll likely look into releasing the updated version of make at some point. Since he's a volunteer (like the rest of us), he'll do it on his own schedule (the bug is relatively minor, and there's a workaround, so this probably won't happen soon). Actually, I think I've said on more than one occasion that I'm waiting for an official upstream make release before I make the next cygwin release of 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: May g++ output windows-style paths instead of cygwin-style one?
On Tue, 16 Aug 2005, Christopher Faylor wrote: On Tue, Aug 16, 2005 at 10:29:17AM -0400, Igor Pechtchanski wrote: This particular problem must've been fixed by some other patch. Nonetheless, now that the make maintainer is aware that there is a bug, he'll likely look into releasing the updated version of make at some point. Since he's a volunteer (like the rest of us), he'll do it on his own schedule (the bug is relatively minor, and there's a workaround, so this probably won't happen soon). Actually, I think I've said on more than one occasion that I'm waiting for an official upstream make release before I make the next cygwin release of make. Ok, so you looked into it (at some point) and decided to wait until an upstream release (which probably won't happen soon). You gotta admit, I was close... :-) Seriously, though -- since your policy is to only package upstream releases of make, maybe stating this in future announcements would quell some of the requests for updates... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA -- 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: May g++ output windows-style paths instead of cygwin-style one?
Brian Dessent wrote: Angel Tsankov wrote: Is there any way I can force the cygwin build of g++ to output folders using windows style (e.g. c:\folder\file) instead of cygwin style (/cygdrive/c/folder/file) when writing dependency files (-MM option)? No, there's no way to do that. Actually, there is: if the input path names to gcc/g++ are windows-style, it will happily emit windows-style paths to the -M output: % gcc -M /cygdrive/c/Shankar/foo.c foo.o: /cygdrive/c/Shankar/foo.c % gcc -M c:/Shankar/foo.c foo.o: c:/Shankar/foo.c And just to remind the OP: c:/Shankar *IS* a windows-style name (the underlying Win32 API happily takes both \ and / as directory separators). So you just have to define the directories in your Makefile using Windows-style paths, and preferably use / to avoid escape-related problems.. -- 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/
