[bug #18872] problem colon after drive letter in prerequisite
Follow-up Comment #3, bug #18872 (project make): I'm fairly confident that cygwin's GCC will only generate dos-style paths in the output dependency files if you pass it in dos-style paths on the commandline or in #include statements. If it were to do so for any other reason, that would indeed be a bug, and I'd be very glad to see a testcase posted to the cygwin mailing list. cheers, DaveK ___ Reply to this item at: http://savannah.gnu.org/bugs/?18872 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #18561] Why backslash line continuation introduce an extra space
Update of bug #18561 (project make): Status:None = Not A Bug Open/Closed:Open = Closed ___ Follow-up Comment #1: It is by design; in fact it's mandated by the POSIX standard for make, which states: When an escaped newline (one preceded by a backslash) is found anywhere in the makefile except in a command line, it shall be replaced, along with any leading white space on the following line, with a single space. Since there is no limit to the length of a physical line in a makefile in GNU make, I suggest you only break physical lines at whitespace. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18561 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #18641] GNUmake 3.81, $(error ) sometimes unable to stop make process
Update of bug #18641 (project make): Status:None = Not A Bug Open/Closed:Open = Closed ___ Follow-up Comment #2: I understand that this is an undocumented change in behavior. However, I think the new behavior is consistent with the documentation... if the user suggests that the file does not need to exist for inclusion via -include then it makes sense to me that a failure to build that file should not cause make to exit. I think what you really want is a solution to bug #102, so that you can have mandatory include files but not get any warnings/errors unless they really can't be built. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18641 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #18641] GNUmake 3.81, $(error ) sometimes unable to stop make process
Follow-up Comment #3, bug #18641 (project make): Thanks a lot for your reply, Paul. You catch my meaning right. I believe that the include warning suppression is expected for nearly every person using GNUmake. People use the ``gcc -M' technique mentioned in GNU make manual to generate .d files to be included into their makefiles, so, if you do not provide a way to suppress that warning, they will see a lot of No such file or directory warnings for .d files when they start a clean build. Could you tell me how you're going to solve this (in make 3.82 for example) and at the same time try to maintain makefile behavior compatibility across at least 3.82, 3.81 and 3.80 ? And perhaps you can have a look at my GnumakeUniproc project just submitted to sf.net: https://gnumakeuniproc.svn.sourceforge.net/svnroot/gnumakeuniproc/GMU-manual/trunk/quick-start/quick-start.htm ___ Reply to this item at: http://savannah.gnu.org/bugs/?18641 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #18641] GNUmake 3.81, $(error ) sometimes unable to stop make process
Follow-up Comment #4, bug #18641 (project make): The method for auto-generating dependencies described in the GNU make manual is not the state-of-the-art method. You should check my website http://make.paulandlesley.org and look at the advanced auto-dependency generation description there. This process was created fro automake by Tom Tromey and it's much superior to the process in the GNU make manual. And, it doesn't suffer from this issue of invalid warnings. The solution to the problem is just as described in bug #102; the message about makefiles not being rebuildable would be deferred until after the makefile has tried to be created and only printed if it couldn't be. I don't see any issue with backward compatibility in this. I took a very quick look at the SF page but there wasn't much there: no homepage, no docs that I could find, etc. If you want to discuss it, probably the help-make@gnu.org mailing list is the best place. Cheers! ___ Reply to this item at: http://savannah.gnu.org/bugs/?18641 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
