[bug #15720] Expansion of variables inside export fails on Win32
Follow-up Comment #3, bug #15720 (project make): Indeed you're correct. My Win32 build of GNU make 3.81beta4 detects my Cygwin sh.exe automatically and makes use of it without a warning. Mixing Cygwin sh.exe with non-Cygwin app such as win32-make.exe can be problematic. So I wrote a simple Bourne Shell simulator in Perl, and instructed `make' to use that, and variable exporting turns right since then: C:\Temptype Makefile bar: export foo := foo bar: ; @echo $(foo) $$foo C:\Tempwin32-make foo C:\Tempwin32-make SHELL = perl G:\script\sh foo foo However, I can't simply move the `perl G:\script\sh' thing from command line into the Makefile itself because of [bug #15718]. The screen-shot is as follows: C:\Temptype Makefile SHELL = perl G:\script\sh bar: export foo := foo bar: ; @echo $(foo) $$foo C:\Tempwin32-make foo P.S. Please don't assume that people who worfk on the Windows port don't run the test suite. I ran the entire test suite when I built the last beta, and everything worked as expected. Glad you run the test suit as me. :=) That was solely a bad joke, please don't take it personally. I appologize for my rudeness. Frankly speeking, the Win32 port of `make' is cute. You all have done a good job. Blessings, Agent ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15720 ___ 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 #15718] Weird behavior of the SHELL variable on Win32
Follow-up Comment #3, bug #15718 (project make): If you want to have Perl execute a program on the command line you have to give it the -e option (see the Perl manual). Running perl foo causes Perl to try to execute the file named foo. If you want to run a Perl script on the command line, which is what make wants to do, then you have to use -e. Now the bad news: make doesn't support this. Make always invokes its commands using the syntax $(SHELL) -c script, and there's no way to change that -c to anything else. This is something I've long considered fixing, by adding a SHELLFLAGS variable or something that could be overridden by the makefile--even in UNIX without changing SHELL this is handy; some people would prefer to invoke /bin/sh with the -e option as well as the -c option. The only way to get around it right now is write a little script wrapper that takes arguments of the form make provides, then invokes Perl with the proper translation of those arguments. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15718 ___ 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 #15718] Weird behavior of the SHELL variable on Win32
Follow-up Comment #4, bug #15718 (project make): Hi, Paul~ Everything you said is very true. I'm a Perl programmer and I know what `perl foo' and `perl -e foo' do. And I know GNU make always sends `-c' to the shell as well. Furthermore, I also quite agree the idea of SHELLFLAGS and the current workaround by writing a wrapper around the perl interpreter, and etc, etc, etc. But, unfortunately, you seem to miss my point in [comment #2]. Sorry, I didn't make my point clear enough. I think I have to rephrase it here: * SHELL variable assignment within Makefile doesn't work for Win32 port of GNU make. That's the bug. * SHELL variable assignment on the command line does work for Win32 port of GNU make. That's what we expect In the screen-shot given in my previous [comment #2], cygwin-make *did* the right thing although it complains. BUT, win32-make did *NOT* do the right thing. win32-make should have complained but it didn't. win32-make apparently did not even try to use `perl' as the shell at all. It must looked back to my Cygwin sh.exe or something instead of `perl', the value of the SHELL varaible in the Makefile. That's all. :=) This bug really has nothing to do with `perl'. `perl' is just an arbitrary sample value, just as what Eli said in [comment #1]. For another example demonstrating this bug, please take a look at my [comment #3] for [bug #15720]. Thank you for your patience. :P Respectfully, Agent ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15718 ___ 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 #15584] 3.81.b4 much slower than 3.80 in some situations
Follow-up Comment #11, bug #15584 (project make): Hm. OK. I guess the only question is, why does the older version of GNU make not have this problem? We must have changed the behavior of intermediate files or something that caused this change in behavior. If we can understand what change we made and that it was legitimate (to fix another bug) then I'm happy to leave this alone for 3.81. Thanks for looking into this one Boris! ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15584 ___ 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 #15741] line numbers reported for $(error) incorrect when following define's
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15741 Summary: line numbers reported for $(error) incorrect when following define's Project: make Submitted by: None Submitted on: Mon 02/13/06 at 16:12 Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Component Version: 3.80 Platform Version: MS Windows Fixed Release: None ___ Details: Line numbers reported for $(error) incorrect when following define's. For each define block, the line number reported by $(error) undercounts the actual value by 1. AFAIK, this is different from bug #106 ... the line number reported is not related to the problem at all. Attached reproduce case was run under cygwin Make v3.80. ___ File Attachments: --- Date: Mon 02/13/06 at 16:12 Name: Makefile Size: 122B By: None reproduce case http://savannah.gnu.org/bugs/download.php?item_id=15741item_file_id=3400 ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15741 ___ 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 #15718] Weird behavior of the SHELL variable on Win32
Follow-up Comment #5, bug #15718 (project make): I was just trying to get the native W32 build to work, as I'm upgrading our build systems from 3.74 to 3.80. We use cmd.exe almost exclusively, and the W32 build broke the system because it refused to use cmd.exe. I examined the source, and in variable.c, the logic for DOS file handling depends on __MSDOS__ which is true for the DJGPP build, but not the native W32 build. The native W32 build uses WINDOWS32 for this purpose and has separate logic. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15718 ___ 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 #15718] Weird behavior of the SHELL variable on Win32
Follow-up Comment #6, bug #15718 (project make): Please try the pretest version of Make 3.81 (beta4). This problem should be fixed in that version. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15718 ___ 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 #15718] Weird behavior of the SHELL variable on Win32
Follow-up Comment #7, bug #15718 (project make): Let me clarify: Comment #6 is for Doug Konrad. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15718 ___ 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 #15718] Weird behavior of the SHELL variable on Win32
Follow-up Comment #8, bug #15718 (project make): Here's a response to Comments #2 and #5: It's not true that ``SHELL variable assignment within Makefile doesn't work for Win32 port of GNU make''. It's just that it's a bit tricky, and also your test Makefile was too simple to force Make to invoke the shell. Try this Makefile instead: SHELL = perl.exe all: ; echo 'hello Note: the unmatched single quote is intentional (it forces Make to invoke the shell)! Also note that the .exe extension is currently required, since Make looks for the shell's file name without appending executable extensions (I think this is a misfeature, so I will try to fix it soon). With these changes in the Makefile, I see with the latest beta of Make 3.81 the same behavior as you see in the Cygwin build. P.S. In general, I think that setting SHELL to anything but a shell, either cmd.exe or some version of Unixy shell, is playing with fire, and not only on Windows: GNU Make assumes too much about the shell (it knows about characters that need special treatment and commands that are built into the shell, for starters). Using a program such as Perl that violates these assumptions will generally cause things to fall apart. Children, don't try that at home! ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15718 ___ 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 #15718] Weird behavior of the SHELL variable on Win32
Follow-up Comment #9, bug #15718 (project make): Just a note: changing SHELL _shouldn't_ be dangerous in the way you mention, Eli. On UNIX, at any rate, if SHELL is not set to an acknowledged value for a Bourne shell then make doesn't even try to use the fast path: all invocations of commands are sent to the SHELL command via the slow path. So, issues of quoting, etc. are not relevant: the whole thing is handed to the shell regardless and whatever quoting rules apply there will be followed. Note that, since you changed SHELL, it's obviously up to you to ensure that your commands work properly! If that's not the case in Windows (and from what you've written here it doesn't appear to be) then that's a bug. The only real problem for changing the shell is the one I mentioned in comment #3: there's no way to change the argument from -c to something else (or nothing). So if the program you want to use for SHELL doesn't grok -c you have to wrap it in something that does. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15718 ___ 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 #15719] Make jobserver feature not supported on WINDOWS32 platforms
Update of bug #15719 (project make): Item Group: Bug = Enhancement Summary: Parallelism with included files in recursive calling becomes serialized on Win32 = Make jobserver feature not supported on WINDOWS32 platforms ___ Follow-up Comment #2: I'm recategorizing this as an enhancement and changing the title to reflect the issue. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15719 ___ 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 #15720] Expansion of variables inside export fails on Win32
Update of bug #15720 (project make): Status:None = Not A Bug Open/Closed:Open = Closed ___ Follow-up Comment #4: I'm closing this as a misunderstanding; I think any real errors here are covered adequately by bug #15718. BTW, if someone has any ideas on how to make the test suite more portable, so it doesn't rely on having a UNIX shell, I'm interested. But, only if it can be done in a fairly clean manner. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15720 ___ 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 #15718] Weird behavior of the SHELL variable on Win32
Follow-up Comment #10, bug #15718 (project make): I'm not sure it's a bug in the Windows port that an arbitrary value of SHELL does not immediately goto slow; after all, it's hard to imagine radically different quoting rules for the relatively simple-minded shells we have on WIndows. But I will think about this some more when I find time to work on this issue. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15718 ___ 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
