Re: [bug #33138] .PARLLELSYNC enhancement with patch
From: Paul Smith psm...@gnu.org Cc: Frank Heckenbach f.heckenb...@fh-soft.de, bug-make@gnu.org Date: Sun, 21 Apr 2013 19:30:05 -0400 On Fri, 2013-04-19 at 14:09 +0300, Eli Zaretskii wrote: Date: Fri, 19 Apr 2013 11:54:05 +0200 Cc: bo...@kolpackov.net, bug-make@gnu.org From: Frank Heckenbach f.heckenb...@fh-soft.de Is there a simple enough Makefile somewhere that could be used to test this feature, once implemented? We have a test in the test suite (output-sync). Can you use that? I hoped for something simpler and not involving Perl or Unixy shell features, because I'd like to use this in the native Windows environment, where the Windows port of Make runs. However, if that's the best possibility, I guess I'd craft something based on that test. The basic feature can be tested trivially like this: all: one two one two: @echo start $@ @sleep 1 @echo stop $@ Now if you run this using make -j you'll get: start one start two stop one stop two If you run this using make -j -O you should get: start one stop one start two stop two There's more to test than that: before it's done we need to test recursive make invocations for example. But the above is simple. Thanks, I tested this, and also the recursive behavior. But I'm not sure whether the results in some less-than-trivial cases are as intended (although I see exactly the same behavior on GNU/Linux, so the questions below are not Windows-specific). E.g., with this Makefile, called mkfsync, (indented 2 spaces for clarity): all: simple recursive simple: one two one two: @echo start $@ @sleep 1 @echo stop $@ @-false recursive: rec1 rec2 rec1 rec2: @echo start $@ $(MAKE) -f mkfsync simple @echo stop $@ and invoking Make as gnumake -j -O -f mkfsync, I get this output: gnumake -f mkfsync simple gnumake -f mkfsync simple mkfsync:6: recipe for target 'one' failed gnumake: [one] Error 1 (ignored) start one stop one mkfsync:6: recipe for target 'two' failed gnumake: [two] Error 1 (ignored) start two stop two start rec1 gnumake[1]: Entering directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' gnumake[1]: Entering directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' mkfsync:6: recipe for target 'one' failed gnumake[1]: Leaving directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' gnumake[1]: Entering directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' gnumake[1]: [one] Error 1 (ignored) gnumake[1]: Leaving directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' gnumake[1]: Entering directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' start one stop one gnumake[1]: Leaving directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' gnumake[1]: Entering directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' mkfsync:6: recipe for target 'two' failed gnumake[1]: Leaving directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' gnumake[1]: Entering directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' gnumake[1]: [two] Error 1 (ignored) gnumake[1]: Leaving directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' gnumake[1]: Entering directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' start two stop two gnumake[1]: Leaving directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' gnumake[1]: Leaving directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' stop rec1 start rec2 gnumake[1]: Entering directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' gnumake[1]: Entering directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' mkfsync:6: recipe for target 'one' failed gnumake[1]: Leaving directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' gnumake[1]: Entering directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' gnumake[1]: [one] Error 1 (ignored) gnumake[1]: Leaving directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' gnumake[1]: Entering directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' start one stop one gnumake[1]: Leaving directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' gnumake[1]: Entering directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' mkfsync:6: recipe for target 'two' failed gnumake[1]: Leaving directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' gnumake[1]: Entering directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' gnumake[1]: [two] Error 1 (ignored) gnumake[1]: Leaving directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' gnumake[1]: Entering directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' start two stop two gnumake[1]: Leaving directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' gnumake[1]: Leaving directory 'D:/gnu/make-3.82.90_GIT_2013-04-20' stop rec2 Is this intended behavior that these two messages: mkfsync:6: recipe for target 'two' failed gnumake[1]: [two] Error 1 (ignored) are separated and wrapped by separate Entering...Leaving blocks, instead of being produced together? They are both produced by a call to 'message', which outputs the message to stdout, so it's not like they went to two different
Re: [bug #33138] .PARLLELSYNC enhancement with patch
Date: Sat, 27 Apr 2013 13:09:02 +0300 From: Eli Zaretskii e...@gnu.org Cc: f.heckenb...@fh-soft.de, bug-make@gnu.org The basic feature can be tested trivially like this: all: one two one two: @echo start $@ @sleep 1 @echo stop $@ Now if you run this using make -j you'll get: start one start two stop one stop two If you run this using make -j -O you should get: start one stop one start two stop two There's more to test than that: before it's done we need to test recursive make invocations for example. But the above is simple. Thanks, I tested this, and also the recursive behavior. The changes needed to make -O work on MS-Windows are now committed to the master repository, see commits da7df54 and 049f8e8. Please review and comment. I also took liberty in committing a small change posted by Frank in this thread, whereby, if taking the semaphore fails, output is dumped unsynchronized, instead of being silently ignored. (Btw, I don't see Frank's assignment on file for Make, so I marked this change tiny, per the FSF procedures.) Thanks to all who contributed to this (lengthy) discussion and allowed me to understand how to implement this feature on Windows. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #33138] .PARLLELSYNC enhancement with patch
On Sat, 2013-04-27 at 13:09 +0300, Eli Zaretskii wrote: Is this intended behavior that these two messages: mkfsync:6: recipe for target 'two' failed gnumake[1]: [two] Error 1 (ignored) are separated and wrapped by separate Entering...Leaving blocks, instead of being produced together? They are both produced by a call to 'message', which outputs the message to stdout, so it's not like they went to two different streams. Am I missing something? Frank mentioned this as well and it's a bug that needs to be fixed. I'll look into it this weekend. I need to check the algorithm; one simple fix, if it's too complex to do it another way, would be to have make write (append) the error message to the temp file rather than printing it directly. That way we know it will come out in the right order when the temp file is dumped to stdout. However that may not be necessary. If this is intended behavior, can we somehow cut down on these Entering...Leaving pairs? They add a lot of clutter and make it hard to read the output of a Make run. Yes, this was also discussed: I've been thinking about a separate way to allow the user to choose. We also need to ensure, as best as we can, that extra unneeded lines are not being generated. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #33138] .PARLLELSYNC enhancement with patch
On Sat, 2013-04-27 at 14:39 +0300, Eli Zaretskii wrote: The changes needed to make -O work on MS-Windows are now committed to the master repository, see commits da7df54 and 049f8e8. Please review and comment. Thanks Eli!! I'll take a look over the next few days. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: .ONESEHLL not working as expected in 3.82
Date: Mon, 30 Aug 2010 17:09:51 +0100 From: Anjum Naseer a.nas...@resilientplc.com I have built the 3.82 version of GNU Make using the Microsoft Visual C++ compiler and it seems to work fine. However, I cannot get it to work correctly with the .ONESHELL option. I created a dummy makefile (dummy.mak) with this content: .ONESHELL: .PHONY: dummy dummy: set xyz=abc @echo xyz=%xyz% If I invoke this with make -d -r -f dummy.mak I get: Vvvv GNU Make 3.82 Built for Windows32 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Reading makefiles... Reading makefile `dummy.mak'... Updating makefiles Considering target file `dummy.mak'. Looking for an implicit rule for `dummy.mak'. No implicit rule found for `dummy.mak'. Finished prerequisites of target file `dummy.mak'. No need to remake target `dummy.mak'. Updating goal targets Considering target file `dummy'. File `dummy' does not exist. Finished prerequisites of target file `dummy'. Must remake target `dummy'. Invoking recipe from dummy.mak:6 to update target `dummy'. Creating temporary batch file C:\Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat Batch file contents: @echo off set xyz=abc set xyz=abc CreateProcess(C:\Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat,C:\ Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat,...) Putting child 0094AFB8 (dummy) PID 9620224 on the chain. Live child 0094AFB8 (dummy) PID 9620224 Main thread handle = 0054 Reaping winning child 0094AFB8 PID 9620224 Cleaning up temp batch file C:\Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat Creating temporary batch file C:\Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat Batch file contents: @echo off echo xyz=%xyz% CreateProcess(C:\Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat,C:\ Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat,...) Live child 0094AFB8 (dummy) PID 9620224 xyz= Reaping winning child 0094AFB8 PID 9620224 Cleaning up temp batch file C:\Users\ADB14~1.NAS\AppData\Local\Temp\make5868-1.bat Removing child 0094AFB8 PID 9620224 from chain. Successfully remade target file `dummy'. As you can see from the debug trace above, it looks like it is still loading a separate SHELL for each line of the recipe. Have I misunderstood the .ONESHELL feature or is this a bug? (Yes, this was almost 3 years ago. Sorry for a long delay.) The .ONESHELL feature is now supported on MS-Windows, for the default Windows shell (cmd.exe) or compatible replacements, in the development version (commit e56aad4). I realize that one of the important use cases for .ONESHELL is to use a shell that Make knows nothing about, but as such shells are not yet supported by the Windows build, I didn't feel it was right to postpone .ONESHELL any longer. Volunteers are welcome to contribute support for foreign shells. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #38827] Make tool does not work for pre-build steps with parallel build option
Update of bug #38827 (project make): Status:None = Not A Bug Open/Closed:Open = Closed ___ Follow-up Comment #1: This is not a bug. By declaring dummyfolder to be a prerequisite of my-main-rule, make must either build it or it must already exist. It doesn't exist, and there's no rule to build it (make has no way to know that the pre-build rule will create the dummyfolder target). Further, although my-main-rule will not start until after pre-build and dummyfolder are both built, there is nothing at all here that says that dummyfolder can't start as soon as possible, before pre-build is complete. So make tries to build dummyfolder and fails. In general it's best if you never try to have rules do tricky things like build targets which are not specifically declared in makefiles. However, the bug tracker is not the best place for these kinds of discussions. Please request assistance on the help-m...@gnu.org mailing list. ___ Reply to this item at: http://savannah.gnu.org/bugs/?38827 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #2520] Add option for alternate default makefile
Update of bug #2520 (project make): Status:None = Not A Bug Open/Closed:Open = Closed ___ Follow-up Comment #1: This bug seems to have been corrupted, or else no description was given: either way I don't know what it's asking. ___ Reply to this item at: http://savannah.gnu.org/bugs/?2520 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #37065] $(wildcard dir/*/.) is wrong (worked fine in 3.81)
Update of bug #37065 (project make): Triage Status:None = Need Info ___ Reply to this item at: http://savannah.gnu.org/bugs/?37065 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #31150] The make doesn't work on Windows x64 platforms
Update of bug #31150 (project make): Triage Status:None = Need Info ___ Follow-up Comment #1: Hi, Could you perhaps show a minimal Makefile that reproduces the problem? Also, is this a 64-bit build of Make or a 32-bit build? If this is a 64-bit build, which compiler was used to build it? ___ Reply to this item at: http://savannah.gnu.org/bugs/?31150 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #30730] SHELL does not work correctly on Windows
Update of bug #30730 (project make): Severity: 3 - Normal = 1 - Wish Item Group: Bug = Enhancement Status:None = Later Triage Status:None = Major Effort ___ Follow-up Comment #1: Make on Windows currently supports only the default Windows shell cmd.exe or compatible replacements, or ports of Unixy shells, such as the ported Bash. Volunteers are welcome to contribute code for other shells, including PowerShell. ___ Reply to this item at: http://savannah.gnu.org/bugs/?30730 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #24405] BATCH_MODE_ONLY_SHELL configuration fails with unixy shells
Update of bug #24405 (project make): Status:None = Fixed Open/Closed:Open = Closed Fixed Release:None = 3.82 Triage Status:None = Verified ___ Follow-up Comment #2: This bug was fixed in Make 3.82. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24405 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #20550] Crash with setting SHELL from the commandline
Update of bug #20550 (project make): Status:None = Fixed Open/Closed:Open = Closed Fixed Release:None = 3.82 Triage Status:None = Verified ___ Follow-up Comment #6: This bug was fixed in Make 3.82. ___ Reply to this item at: http://savannah.gnu.org/bugs/?20550 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #20542] Regression: windows gnumake + MKS shell + Special Shell Chars
Update of bug #20542 (project make): Item Group: Bug = Enhancement Status:None = Works for me Triage Status:None = Need Info ___ Reply to this item at: http://savannah.gnu.org/bugs/?20542 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #17433] Enhancement in process creation functions in sub_proc.c
Update of bug #17433 (project make): Severity: 3 - Normal = 1 - Wish Status:None = Fixed Open/Closed:Open = Closed Fixed Release:None = 3.82 ___ Follow-up Comment #2: I'm closing this bug because most of it was already fixed, and the rest isn't important enough IMO. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17433 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #17277] Pathes longer than 128 Chars fail with make under windows
Update of bug #17277 (project make): Open/Closed:Open = Closed Fixed Release:None = 3.82 Triage Status:None = Verified ___ Reply to this item at: http://savannah.gnu.org/bugs/?17277 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #16476] WINDOWS32 vs. HAVE_ANSI_COMPILER macros
Update of bug #16476 (project make): Open/Closed:Open = Closed Fixed Release:None = 3.82 ___ Follow-up Comment #6: I'm closing this bug because too much time has passed, and the code in question has likely changed beyond recognition. So have the MS compilers and environments. If this problem is still relevant, please reopen with the current state of affairs, and we will take it from there. ___ Reply to this item at: http://savannah.gnu.org/bugs/?16476 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #7201] Windows Path search works incorrectly
Update of bug #7201 (project make): Status:None = Wont Fix Open/Closed:Open = Closed ___ Follow-up Comment #4: I'm closing this bug because I think Make on Windows behaves exactly as the shell would if it were to invoke the program. If there are situations where the above is incorrect, please feel free to reopen with relevant information. ___ Reply to this item at: http://savannah.gnu.org/bugs/?7201 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: .ONESEHLL not working as expected in 3.82
From: Paul Smith p...@mad-scientist.net Cc: make-...@gnu.org, bug-make@gnu.org Date: Sat, 27 Apr 2013 12:54:10 -0400 Also, I wonder if you have a few minutes to go through the open Windows bugs in Savannah and make a comment or whatever to those which are still waiting (some are waiting for other people, not us). Looks like 18 bugs total, some pretty old. Here's a link I hope will work for you: https://savannah.gnu.org/bugs/index.php?go_report=Applygroup=makefunc=browseset=custommsort=0report_id=141advsrch=0status_id=1platform_version_id=105fix_release_id=100 Thanks. I went through that list and closed several bugs, either because they were fixed or because they sound no longer relevant. There are now only 11 open issues in that list. Out of those 11, I will try to find time to work on about 2 or 3; the rest are either enhancements (4 of them) that don't sound too important to me (volunteers are welcome, of course), or await for additional information without which I cannot advance in my investigation of the issue. Note: there's one more major feature in current git repo that needs to be made available on Windows: dynamic loading of extensions. That is my highest priority for Make todo list. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: .ONESEHLL not working as expected in 3.82
On Sat, 2013-04-27 at 20:55 +0300, Eli Zaretskii wrote: Note: there's one more major feature in current git repo that needs to be made available on Windows: dynamic loading of extensions. That is my highest priority for Make todo list. Yes. I wonder if there are features of gnulib which make this work in a cross-platform way? I've often wondered if we might get some win out of utilizing gnulib more in GNU make code. However, I think that investigation and reworking will need to wait until after the next release. I don't want to open that can of worms yet... at least not widely. But if you see something there that would make your work for load simpler let me know and we'll look into it. One other thing: I want to make a format cleanup commit at some point to deal with a number of annoying issues related to TABs, EOL syntax, etc., as well as update copyright dates, etc. I don't want to do that when it will conflict with major work anyone else is doing, so let me know when a good time is for you. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: .ONESEHLL not working as expected in 3.82
From: Paul Smith psm...@gnu.org Cc: make-...@gnu.org, bug-make@gnu.org Date: Sat, 27 Apr 2013 14:28:18 -0400 On Sat, 2013-04-27 at 20:55 +0300, Eli Zaretskii wrote: Note: there's one more major feature in current git repo that needs to be made available on Windows: dynamic loading of extensions. That is my highest priority for Make todo list. Yes. I wonder if there are features of gnulib which make this work in a cross-platform way? I've often wondered if we might get some win out of utilizing gnulib more in GNU make code. AFAICS, gnulib does not offer any modules that support dynamic loading of shared libraries. However, I think that investigation and reworking will need to wait until after the next release. I don't want to open that can of worms yet... at least not widely. But if you see something there that would make your work for load simpler let me know and we'll look into it. I added a similar facility to Gawk, but there a problem was much simpler, because Gawk itself was tracking the loaded extensions in platform-independent code. So my emulation of dlopen didn't need to support NULL as its first argument, and didn't care about RTLD_GLOBAL. By contrast, the way Make's code in load.c is written, it relies on dlopen to track the shared libraries already loaded. This is a PITA on Windows, because there's no similar functionality built in, and the emulation of dlopen will have to record each loaded extension in some internal data structure, and search that when dlopen is called with its 1st argument NULL. Not rocket science, granted, but it does make the job larger and the required testing more extensive. If Make could behave like Gawk, I could have simply copied the code I wrote for Gawk and reuse it almost verbatim. One other thing: I want to make a format cleanup commit at some point to deal with a number of annoying issues related to TABs, EOL syntax, etc., as well as update copyright dates, etc. I don't want to do that when it will conflict with major work anyone else is doing, so let me know when a good time is for you. As far as I'm concerned, you can do it whenever you want. I'd be greatly surprised if git couldn't figure out how to merge stuff like that cleanly. CVS could have barfed, but not git (or any other modern VCS that tracks the history DAG). ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: .ONESEHLL not working as expected in 3.82
I took with make-w32 list off. On Sat, 2013-04-27 at 22:18 +0300, Eli Zaretskii wrote: I added a similar facility to Gawk, but there a problem was much simpler, because Gawk itself was tracking the loaded extensions in platform-independent code. So my emulation of dlopen didn't need to support NULL as its first argument, and didn't care about RTLD_GLOBAL. By contrast, the way Make's code in load.c is written, it relies on dlopen to track the shared libraries already loaded. This is a PITA on Windows, because there's no similar functionality built in, and the emulation of dlopen will have to record each loaded extension in some internal data structure, and search that when dlopen is called with its 1st argument NULL. Not rocket science, granted, but it does make the job larger and the required testing more extensive. Well, we already maintain a list of modules that are loaded in the .LOADED variable. Although it's not written like that today, I have no problem changing the code to check that variable to see whether the module is loaded or not. We already make that check, to ensure we don't call the user's init function twice. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: .ONESEHLL not working as expected in 3.82
From: Paul Smith psm...@gnu.org Cc: bug-make@gnu.org Date: Sat, 27 Apr 2013 15:32:22 -0400 Well, we already maintain a list of modules that are loaded in the .LOADED variable. Although it's not written like that today, I have no problem changing the code to check that variable to see whether the module is loaded or not. That would be nice, indeed. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: .ONESEHLL not working as expected in 3.82
On Sat, 2013-04-27 at 23:00 +0300, Eli Zaretskii wrote: That would be nice, indeed. OK, pushed. You should be able to simply write a new load_objects() function and drop it in. Or put it into a w32 file or whatever. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #33138] .PARLLELSYNC enhancement with patch
On Thu, 2013-04-18 at 22:36 +0200, Frank Heckenbach wrote: This is useful (to me) because at any time, I know what's running. ([Start] messages minus [End] messages.) Thanks, this is the reason I was looking for; that use-case wasn't clear to me based on the previous email. OK, so what are we going to do about it? Leave, revert, new option? I've pushed a change to add a new argument to the -O/--output-sync option, job, to write output after each line of the recipe. Please give it a try and make sure it works for your situation. It worked OK in my more limited testing. I'm not excited about that term (job); it's kind of accurate, but in the documentation for example we're really mushy about exactly what a job is, vs. a recipe or a command line etc. I'd like to pick some terms for this, define them in a solid way, then clean up the references. It would be best to do this before the release to avoid changing things later. For example, we currently use target as the name; maybe recipe is better? If anyone has opinions I'm listening. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #37065] $(wildcard dir/*/.) is wrong (worked fine in 3.81)
Update of bug #37065 (project make): Triage Status: Need Info = None ___ Follow-up Comment #4: Hi Eli; there's a makefile attached. It's maybe not everything we'd wish for in a repro case but it seems to be enough to try. Something like this (but translated to Windows): mkdir foo mkdir foo/bar touch foo/baz echo '$(info $(wildcard foo/*/.))' | make -f- should show just foo/bar/. Rossen appears to be saying that on Windows, this will show foo/bar/. foo/baz/. which is clearly not correct. I'm resetting the triage status: if this example doesn't work for you please update again. Cheers! ___ Reply to this item at: http://savannah.gnu.org/bugs/?37065 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
