Re: 3.81 and windows paths
> Date: Fri, 28 Jul 2006 17:31:31 -0400 > From: "Paul D. Smith" <[EMAIL PROTECTED]> > Cc: > > Hm. I just can't think of any but the most obscure cases where this is > true. The DOS pathname handling in vanilla GNU make, as far as I know, > is very specific: if and ONLY if the first character of a pathname is a > letter and the second is a colon, then the path is considered a DOS > path. The only constructs where the meaning is ambiguous would be very > rare; something like: > > foo : c:bar > > should this be interpreted as a static pattern rule: > > foo : c : bar > > or with the DOS path "c:bar"? In this case it's obvious to us since the > latter leads to a syntax error but of course make doesn't know that when > it's parsing tokens. > > > Any ambiguity is trivially solved by adding whitespace before and/or > after the ":" in target rules. Target rules is one case; another is values given to PATH and VPATH/vpath/GPATH, where a colon is the separator on Posix platforms. > I suppose there might be some backslash issues. I really don't remember > what HAVE_DOS_PATHS does with backslashes in target/prerequisite > pathnames. When HAVE_DOS_PATHS is defined, Make tries very hard to treat backslashes and forward slashes in file names in the same manner. The only case I remember where we intentionally do NOT treat backslashes as forward slashes is in the $wildcard function (and in fact in any other situation that calls `glob' or `fnmatch'). ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: 3.81 and windows paths
%% "John W. Eaton" <[EMAIL PROTECTED]> writes: jwe> On 28-Jul-2006, Paul D. Smith wrote: | This would be very tricky: right now all the code to do DOS vs. POSIX | pathnames is controlled through #ifdefs, so it's a compile-time thing. | Changing it to a runtime thing would be a lot of work, I think... the jwe> OK, but I still think it should be implemented as an optional jwe> feature that users can select unless we can prove that the jwe> feature doesn't cause trouble for valid Makefiles that use only jwe> Posix filenames. As I said, we can definitely say it could cause trouble, but in pretty rare situations (I believe). Whether that's enough to cause Cygwin to reject this option is, ultimately, up to them. Note I'm not even thinking about making this feature available on non-Windows systems as that just doesn't make sense. | #ifdeffing in GNU make is kind of a mess, with all the different ports | we support. jwe> Yes, that's unfortunate. I don't think that it is necessary to jwe> use an intricate mess of #ifdefs all throughout a program to jwe> achieve portability to a wide variety of systems. That seems to jwe> be a design decision that was made fairly early on in the jwe> development of Make (long before you became the maintainer, I jwe> would guess). Yes, it's too bad. Supporting wildly different host platforms can be done much more cleanly BUT you need to do a lot of up-front work and put a lot of thought into it. Or, you can have something similar to Apache's APR library or whatever available to you. Obviously the GNU make ports weren't handled that way, for quite reasonable reasons. Even so there's a lot of room to clean this up now, but not a lot of incentive I suppose. I asked on some Amiga mailing lists whether that port was still used and useful; if it wasn't I was going to rip it out which would have helped a good bit. But, by gosh, some people actually still do use it! The next version of GNU make will require an ISO 1989 C compiler and runtime library and give up supporting pre-standard K&R compilers. That will help a tiny little bit. -- --- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: 3.81 and windows paths
%% Christopher Faylor <[EMAIL PROTECTED]> writes: >> Or is there something special going on that means this won't work? cf> I think this has been answered later in the thread, but the short answer cf> is - the MinGW make won't recognize the cygwin mount table or symlinks, cf> so you can't use cygwin paths in a MinGW makefile without resorting to cf> something like "cygpath". Aha. Gotcha. Yes that would be a problem. >> Regardless, I still wonder whether my idea of building make for a POSIX >> environment with Cygwin, but setting HAVE_DOS_PATHS explicitly, would >> work. cf> I briefly thought that this might be a possibility but I've since cf> remembered cases where people complained about their linux cf> makefiles not working correctly due to the colon handling in 3.80. Hm. I just can't think of any but the most obscure cases where this is true. The DOS pathname handling in vanilla GNU make, as far as I know, is very specific: if and ONLY if the first character of a pathname is a letter and the second is a colon, then the path is considered a DOS path. The only constructs where the meaning is ambiguous would be very rare; something like: foo : c:bar should this be interpreted as a static pattern rule: foo : c : bar or with the DOS path "c:bar"? In this case it's obvious to us since the latter leads to a syntax error but of course make doesn't know that when it's parsing tokens. Any ambiguity is trivially solved by adding whitespace before and/or after the ":" in target rules. To be clear: I'm certainly not suggesting that enabling HAVE_DOS_PATHS will always behave correctly for any valid POSIX makefile, or even any potentially valid Linux makefile. However, it seems quite rare to run into a conflict, so much so that I'm not sure it's worth worrying about. I suppose there might be some backslash issues. I really don't remember what HAVE_DOS_PATHS does with backslashes in target/prerequisite pathnames. YM, of course, MV :-) -- --- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: 3.81 and windows paths
On 28-Jul-2006, Paul D. Smith wrote: | This would be very tricky: right now all the code to do DOS vs. POSIX | pathnames is controlled through #ifdefs, so it's a compile-time thing. | Changing it to a runtime thing would be a lot of work, I think... the OK, but I still think it should be implemented as an optional feature that users can select unless we can prove that the feature doesn't cause trouble for valid Makefiles that use only Posix filenames. | #ifdeffing in GNU make is kind of a mess, with all the different ports | we support. Yes, that's unfortunate. I don't think that it is necessary to use an intricate mess of #ifdefs all throughout a program to achieve portability to a wide variety of systems. That seems to be a design decision that was made fairly early on in the development of Make (long before you became the maintainer, I would guess). jwe ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: 3.81 and windows paths
On 28-Jul-2006, Chris Taylor wrote: | So even if the DOS #ifdef was enabled, we'd be back at the point of | having patches to attempt to fix this behaviour. | Unless there was some way of having two versions of make - one with this | behaviour and one without, controlled by /etc/alternatives perhaps? Two versions for this seemingly small feature seems a bit much when a command-line switch could do the job. jwe ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: 3.81 and windows paths
Paul D. Smith wrote: %% "John W. Eaton" <[EMAIL PROTECTED]> writes: jwe> On 28-Jul-2006, Paul D. Smith wrote: | Regardless, I still wonder whether my idea of building make for a POSIX | environment with Cygwin, but setting HAVE_DOS_PATHS explicitly, would | work. jwe> If this could cause some valid Makefiles to do the wrong thing as jwe> cgf suggests might happen, Hm. I don't think I saw that message? Certainly there are obscure cases where enabling DOS path support will behave differently, but they're pretty rare I believe. Is this a Cygwin thing? This was a thing where POSIX compatible makefiles were not behaving as expected, which is now believed to be due to the cygwin dos-path handling patches. jwe> then can we at least make the behavior optional, perhaps with a jwe> command line option or magic target (maybe jwe> ".WINDOWS_FILENAMES:")? This would be very tricky: right now all the code to do DOS vs. POSIX pathnames is controlled through #ifdefs, so it's a compile-time thing. Changing it to a runtime thing would be a lot of work, I think... the #ifdeffing in GNU make is kind of a mess, with all the different ports we support. Honestly, I don't see a lot of benefit to it. On a Windows system, even in Cygwin, I would assume that everyone would always expect anything that looked like a Windows pathname to be treated like a Windows pathname. We're not talking about enabling this support on UNIX, just in Cygwin. Well, the whole point of cygwin is to give a POSIX-compatible environment in win32. So it's aiming to be like linux, not windows. This means that if something like a makefile parses fine in linux, but not in cygwin (barring linker stuff), something is wrong. And so on from there.. So even if the DOS #ifdef was enabled, we'd be back at the point of having patches to attempt to fix this behaviour. Unless there was some way of having two versions of make - one with this behaviour and one without, controlled by /etc/alternatives perhaps? Speculation on my part anyway. Chris / EqUaTe ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: 3.81 and windows paths
On 28-Jul-2006, Paul D. Smith wrote: | Regardless, I still wonder whether my idea of building make for a POSIX | environment with Cygwin, but setting HAVE_DOS_PATHS explicitly, would | work. If this could cause some valid Makefiles to do the wrong thing as cgf suggests might happen, then can we at least make the behavior optional, perhaps with a command line option or magic target (maybe ".WINDOWS_FILENAMES:")? That way, people who don't ask for the special feature won't be bitten by it. Thanks, jwe ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: 3.81 and windows paths
Michael Eager wrote: Christopher Faylor wrote: On Thu, Jul 27, 2006 at 05:09:16PM -0400, Paul D. Smith wrote: In fact, I'm wondering if there is an advantage to building GNU make using the Cygwin environment, vs. using a native MingW (for example) build of GNU make? I'm afraid I'm woefully ignorant about the details. There is no advantage using cygwin if you want to use a Makefile which contains MS-DOS paths. Using MinGW makes perfect sense in that case. Despite having suggested this repeatedly, it seems some users are still not clear on this concept. When I ran into this problem, it was because there was a WINDOWS environment symbol referenced in a dependency. It's not practical to change the environment symbol -- it is used by both makefiles and native windows programs. Nor is it practical to re-write the paths in the makefile -- because the makefile needs to reference this (and other) shared environment symbols, which are not fixed in the makefile. There are two equally unpleasant resolutions recommended: either install two products (Cygwin and MinGW) or retain a back-level version of make, forgoing all future bug fixes. Neither are very good, but I've opted for the second choice. You're forgetting the third, correct choice: use cygpath to translate the offending environment variable (if you like, store a copy of the translated variable in make's environment). -- Matthew Warning: prolonged exposure to Cygwin may cause addiction. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: 3.81 and windows paths
On Fri, Jul 28, 2006 at 09:56:20AM -0400, Paul D. Smith wrote: >%% Christopher Faylor writes: >cf> If you want to use a Makefile which works in a Cygwin environment, >cf> however, then obviously you need to build it with a Cygwin gcc. > >You'll have to forgive my virtually complete ignorance of all things >Windows, even Cygwin, but if you have a minute... why? > >I mean, if there is no special Cygwin code in make any longer, then >can't people use a native Windows build of make and have it invoke tools >in the Cygwin environment? > >Or is there something special going on that means this won't work? I think this has been answered later in the thread, but the short answer is - the MinGW make won't recognize the cygwin mount table or symlinks, so you can't use cygwin paths in a MinGW makefile without resorting to something like "cygpath". >Regardless, I still wonder whether my idea of building make for a POSIX >environment with Cygwin, but setting HAVE_DOS_PATHS explicitly, would >work. I briefly thought that this might be a possibility but I've since remembered cases where people complained about their linux makefiles not working correctly due to the colon handling in 3.80. This may have been a side effect of the ancient patches that I had been carrying forward but I have a feeling that there are cases where a makefile which runs on linux could not be properly parsed under cygwin. I mentioned this here: http://cygwin.com/ml/cygwin/2006-07/msg00896.html >cf> Again, I'm sorry for any confusion this may have caused. > >Absolutely no problem Christopher; I hope I didn't sound peeved because >I'm not. I'm happy to see this change, and I'm happy that I understand >the source of the confusion some Cygwin users have been having lately. >It's all good! No, I didn't detect any trace of "peevedness" at all. I just hate when decisions that I make have unintended consequences for other free software volunteers. cgf ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: 3.81 and windows paths
%% "John W. Eaton" <[EMAIL PROTECTED]> writes: jwe> On 28-Jul-2006, Paul D. Smith wrote: | Regardless, I still wonder whether my idea of building make for a POSIX | environment with Cygwin, but setting HAVE_DOS_PATHS explicitly, would | work. jwe> If this could cause some valid Makefiles to do the wrong thing as jwe> cgf suggests might happen, Hm. I don't think I saw that message? Certainly there are obscure cases where enabling DOS path support will behave differently, but they're pretty rare I believe. Is this a Cygwin thing? jwe> then can we at least make the behavior optional, perhaps with a jwe> command line option or magic target (maybe jwe> ".WINDOWS_FILENAMES:")? This would be very tricky: right now all the code to do DOS vs. POSIX pathnames is controlled through #ifdefs, so it's a compile-time thing. Changing it to a runtime thing would be a lot of work, I think... the #ifdeffing in GNU make is kind of a mess, with all the different ports we support. Honestly, I don't see a lot of benefit to it. On a Windows system, even in Cygwin, I would assume that everyone would always expect anything that looked like a Windows pathname to be treated like a Windows pathname. We're not talking about enabling this support on UNIX, just in Cygwin. -- --- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: 3.81 and windows paths
%% Christopher Faylor <[EMAIL PROTECTED]> writes: cf> There is no advantage using cygwin if you want to use a Makefile cf> which contains MS-DOS paths. Using MinGW makes perfect sense in cf> that case. Despite having suggested this repeatedly, it seems cf> some users are still not clear on this concept. Well, I can understand the desire to use a generally POSIX environment, but still have some requirements that it interact with native Windows in some ways. I did read the thread on the cygwin mailing list so I know people could work around it with macros or cygpath or whatever. cf> If you want to use a Makefile which works in a Cygwin environment, cf> however, then obviously you need to build it with a Cygwin gcc. You'll have to forgive my virtually complete ignorance of all things Windows, even Cygwin, but if you have a minute... why? I mean, if there is no special Cygwin code in make any longer, then can't people use a native Windows build of make and have it invoke tools in the Cygwin environment? Or is there something special going on that means this won't work? Regardless, I still wonder whether my idea of building make for a POSIX environment with Cygwin, but setting HAVE_DOS_PATHS explicitly, would work. cf> Again, I'm sorry for any confusion this may have caused. Absolutely no problem Christopher; I hope I didn't sound peeved because I'm not. I'm happy to see this change, and I'm happy that I understand the source of the confusion some Cygwin users have been having lately. It's all good! Cheers! -- --- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: 3.81 and windows paths
Christopher Faylor wrote: On Thu, Jul 27, 2006 at 05:09:16PM -0400, Paul D. Smith wrote: In fact, I'm wondering if there is an advantage to building GNU make using the Cygwin environment, vs. using a native MingW (for example) build of GNU make? I'm afraid I'm woefully ignorant about the details. There is no advantage using cygwin if you want to use a Makefile which contains MS-DOS paths. Using MinGW makes perfect sense in that case. Despite having suggested this repeatedly, it seems some users are still not clear on this concept. When I ran into this problem, it was because there was a WINDOWS environment symbol referenced in a dependency. It's not practical to change the environment symbol -- it is used by both makefiles and native windows programs. Nor is it practical to re-write the paths in the makefile -- because the makefile needs to reference this (and other) shared environment symbols, which are not fixed in the makefile. There are two equally unpleasant resolutions recommended: either install two products (Cygwin and MinGW) or retain a back-level version of make, forgoing all future bug fixes. Neither are very good, but I've opted for the second choice. It seems to me that it should be possible to have the DOS path within quotes, so that it doesn't trigger make's pattern matching syntax. That would be a more acceptable solution than the other two. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077 ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: 3.81 and windows paths
On Thu, Jul 27, 2006 at 05:09:16PM -0400, Paul D. Smith wrote: >In fact, I'm wondering if there is an advantage to building GNU make >using the Cygwin environment, vs. using a native MingW (for example) >build of GNU make? I'm afraid I'm woefully ignorant about the details. There is no advantage using cygwin if you want to use a Makefile which contains MS-DOS paths. Using MinGW makes perfect sense in that case. Despite having suggested this repeatedly, it seems some users are still not clear on this concept. If you want to use a Makefile which works in a Cygwin environment, however, then obviously you need to build it with a Cygwin gcc. I'm *very* sorry that I didn't make it clearer in my release announcement that the change in behavior for cygwin was due to a decision on my part not to try to forward port some old make patches which I have always found questionable. Of course hardly anyone reads release announcemnts, but that would mean that at least some people wouldn't think of this as some sort of generic make bug. It never occurred to me that anyone would be complaining about this in the bug-make mailing list. Again, I'm sorry for any confusion this may have caused. cgf ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: 3.81 and windows paths
> Date: Thu, 27 Jul 2006 17:09:16 -0400 > From: "Paul D. Smith" <[EMAIL PROTECTED]> > Cc: cygwin@cygwin.com, bug-make@gnu.org > > I believe that this support is limited to handling drive letters without > choking on the ":", actually: IIRC the native support still requires > forward slashes (/) rather than backslashes (\). I could be wrong > though. It is indeed safer to use forward slashes throughout in the native Windows port, but backslashes are supported in most places in the Makefile, in particular in rule's commands. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: 3.81 and windows paths
Hi! On 27/07/06 20:50, Bob Rossi wrote: Hi, Is it true that 3.81 does not work with windows paths? If so, what is the solution now? I need to use the unix path interally to make, and use the windows path only when compiling with cl? Could you be a little more specific with what you mean by "windows paths"? Spaces are often an issue with MS-Windows filenames, is that what you mean? README.W32 contains info about the Win32 port. Here is the section on pathnames etc: Pathnames and white space: Unlike Unix, Windows 95/NT systems encourage pathnames which contain white space (e.g. C:\Program Files\). These sorts of pathnames are legal under Unix too, but are never encouraged. There is at least one place in make (VPATH/vpath handling) where paths containing white space will simply not work. There may be others too. I chose to not try and port make in such a way so that these sorts of paths could be handled. I offer these suggestions as workarounds: 1. Use 8.3 notation. i.e. "x:/long~1/", which is actually "x:\longpathtest". Type "dir /x" to view these filenames within the cmd.exe shell. 2. Rename the directory so it does not contain white space. If you are unhappy with this choice, this is free software and you are free to take a crack at making this work. The code in w32/pathstuff.c and vpath.c would be the places to start. Pathnames and Case insensitivity: Unlike Unix, Windows 95/NT systems are case insensitive but case preserving. For example if you tell the file system to create a file named "Target", it will preserve the case. Subsequent access to the file with other case permutations will succeed (i.e. opening a file named "target" or "TARGET" will open the file "Target"). By default, GNU make retains its case sensitivity when comparing target names and existing files or directories. It can be configured, however, into a case preserving and case insensitive mode by adding a define for HAVE_CASE_INSENSITIVE_FS to config.h.W32. For example, the following makefile will create a file named Target in the directory subdir which will subsequently be used to satisfy the dependency of SUBDIR/DepTarget on SubDir/TARGET. Without HAVE_CASE_INSENSITIVE_FS configured, the dependency link will not be made: subdir/Target: touch $@ SUBDIR/DepTarget: SubDir/TARGET cp $^ $@ Reliance on this behavior also eliminates the ability of GNU make to use case in comparison of matching rules. For example, it is not possible to set up a C++ rule using %.C that is different than a C rule using %.c. GNU make will consider these to be the same rule and will issue a warning. SAMBA/NTFS/VFAT: I have not had any success building the debug version of this package using SAMBA as my file server. The reason seems to be related to the way VC++ 4.0 changes the case name of the pdb filename it is passed on the command line. It seems to change the name always to to lower case. I contend that the VC++ compiler should not change the casename of files that are passed as arguments on the command line. I don't think this was a problem in MSVC 2.x, but I know it is a problem in MSVC 4.x. The package builds fine on VFAT and NTFS filesystems. Most all of the development I have done to date has been using NTFS and long file names. I have not done any considerable work under VFAT. VFAT users may wish to be aware that this port of make does respect case sensitivity. FAT: Version 3.76 added support for FAT filesystems. Make works around some difficulties with stat'ing of files and caching of filenames and directories internally. === -- WWW: http://jguk.org/ IM: [EMAIL PROTECTED] ICQ: 11122941 ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: 3.81 and windows paths
%% I wrote: pds> I believe that this support is limited to handling drive letters without pds> choking on the ":", actually: IIRC the native support still requires pds> forward slashes (/) rather than backslashes (\). I could be wrong pds> though. I'm not sure how Cygwin's pathname management patches worked. pds> In fact, I'm wondering if there is an advantage to building GNU make pds> using the Cygwin environment, vs. using a native MingW (for example) pds> build of GNU make? I'm afraid I'm woefully ignorant about the details. Now that I think about this more... There is a separate #define use to enable/disable special handling of DOS pathnames in vanilla GNU make: HAVE_DOS_PATHS This feature is not controlled by the generic WINDOWS32 #define. I don't see any reason, offhand, that HAVE_DOS_PATHS couldn't be set in the Cygwin build of GNU make, even though that build is otherwise using standard POSIX and not the Windows system API. In theory that would very easily allow the Cygwin build of GNU make to continue to be a Cygwin application, but with added support for DOS pathnames similar to what you get if you build for native Windows. Of course I've never tried this combination so there may be more to it (it may use some special functions under the w32 directory, and/or there may be some incorrectly #ifdef'd sections of code that need to be fixed). But, it might be worth pursuing. -- --- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: 3.81 and windows paths
%% Brian Dessent <[EMAIL PROTECTED]> writes: bd> To summarize, the Cygwin version of make prior to 3.81 contained bd> local patches to support both posix and Windows paths. The Cygwin bd> maintainer got tired of continuously maintaining these local bd> patches and so when packaging 3.81 the vanilla sources were used. bd> This means that only posix paths work. Thanks Brian; I had no idea about this decision on the part of the Cygwin maintainers (and the minor brouhaha it apparently generated :-)). Now that I know about this I have a much better understanding of what's going on: I couldn't figure out how upgrading from 3.80 to 3.81 was causing these problems--unfortunately most people neglect to mention they're using Cygwin until asked specifically (heck many don't even mention they're using Windows!! :-/) bd> However, completely separate from Cygwin is the native (mingw) bd> build of make which has always supported Windows paths and always bd> will. So it's completely wrong to say that make doesn't support bd> Windows paths. You should use this version if you need to support bd> such paths. I agree with this: you can build GNU make in 2 or 3 different ways, all of which natively support DOS-style pathnames and have always done since DOS/Windows support was first added back in GNU make 3.76 or so. I believe that this support is limited to handling drive letters without choking on the ":", actually: IIRC the native support still requires forward slashes (/) rather than backslashes (\). I could be wrong though. I'm not sure how Cygwin's pathname management patches worked. In fact, I'm wondering if there is an advantage to building GNU make using the Cygwin environment, vs. using a native MingW (for example) build of GNU make? I'm afraid I'm woefully ignorant about the details. -- --- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: 3.81 and windows paths
On Thu, Jul 27, 2006 at 01:21:07PM -0700, Brian Dessent wrote: > Bob Rossi wrote: > > > Is it true that 3.81 does not work with windows paths? > > If so, what is the solution now? I need to use the unix path > > interally to make, and use the windows path only when compiling > > with cl? > > Please refer to the lengthy discussion on the Cygwin list. > > To summarize, the Cygwin version of make prior to 3.81 contained local > patches to support both posix and Windows paths. The Cygwin maintainer > got tired of continuously maintaining these local patches and so when > packaging 3.81 the vanilla sources were used. This means that only > posix paths work. > > However, completely separate from Cygwin is the native (mingw) build of > make which has always supported Windows paths and always will. So it's > completely wrong to say that make doesn't support Windows paths. You > should use this version if you need to support such paths. > > The only thing that has changed was on the part of the Cygwin make > maintainer, and so this discussion belongs on the Cygwin list (where it > has already been hashed out in length.) Thank you, this is an excellent response. Bob Rossi ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: 3.81 and windows paths
Bob Rossi wrote: > Is it true that 3.81 does not work with windows paths? > If so, what is the solution now? I need to use the unix path > interally to make, and use the windows path only when compiling > with cl? Please refer to the lengthy discussion on the Cygwin list. To summarize, the Cygwin version of make prior to 3.81 contained local patches to support both posix and Windows paths. The Cygwin maintainer got tired of continuously maintaining these local patches and so when packaging 3.81 the vanilla sources were used. This means that only posix paths work. However, completely separate from Cygwin is the native (mingw) build of make which has always supported Windows paths and always will. So it's completely wrong to say that make doesn't support Windows paths. You should use this version if you need to support such paths. The only thing that has changed was on the part of the Cygwin make maintainer, and so this discussion belongs on the Cygwin list (where it has already been hashed out in length.) Brian ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
