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
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
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 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
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
%% 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 KR 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
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
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
