[bug #27714] expansion of $(shell) in target forces serialization of targets
Update of bug #27714 (project make): Status:None = Wont Fix Open/Closed:Open = Closed ___ Follow-up Comment #10: I'm going to close this as won't fix because I don't see any reasonable way to implement it that doesn't involve massive changes to the way make works, and I don't think the capability to have parallel function expansion is worth the effort. If you want to invoke shell commands in a recipe you don't have to run $(shell ...)... the _recipe itself_ is run by the shell so why use the shell function? Just put the commands that the shell function would run directly into the recipe. Then they will be passed to the subshell and run in parallel just like the rest of the command script. ___ Reply to this item at: http://savannah.gnu.org/bugs/?27714 ___ 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 #27714] expansion of $(shell) in target forces serialization of targets
Follow-up Comment #5, bug #27714 (project make): Hrm. The only way this could be fixed would be to make the $(shell ...) function a true make job, so that it takes a job token, can run in the background asynchronously, and is basically handled as an anonymous recipe line that is run before the real recipe line. This would be almost impossible to do, because it would mean we'd have to introduce an entirely new concept in make: the ability to have deferred variable expansion, where we say please expand this string and instead of getting the expanded string back, we'd get back a response saying I started it, come back later. Then later, sometime, we'd have to check to see if it completed, and somehow restart our expansion at that time. Allowing expansion to happen asynchronously would mean completely rewriting a very significant portion of make. ___ Reply to this item at: http://savannah.gnu.org/bugs/?27714 ___ 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 #27714] expansion of $(shell) in target forces serialization of targets
Follow-up Comment #6, bug #27714 (project make): i dont really know how GNU make is architected, but i dont see why make cant fork the process to handle the target and then the subprocess does both deferred expansion and running the commands listed for that target. i'd also point out that other make implementations (such as BSD makes) handle this the way i expect -- in parallel. ___ Reply to this item at: http://savannah.gnu.org/bugs/?27714 ___ 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 #27714] expansion of $(shell) in target forces serialization of targets
Follow-up Comment #7, bug #27714 (project make): I'm surprised you say you can do this with BSD make; I'm not aware that BSD make has any feature like the $(shell ...) function, that can appear inside a recipe. What syntax do you use for this in BSD make? We can't expand the recipe in a forked version of GNU make, because the expansion of the recipe can have side-effects (for example, if an $(eval ...) is expanded); if the expansion happens in a forked process then those side effects are not available in the parent. ___ Reply to this item at: http://savannah.gnu.org/bugs/?27714 ___ 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 #27714] expansion of $(shell) in target forces serialization of targets
Follow-up Comment #4, bug #27714 (project make): i understand what you're saying, but i think the behavior you describe as expected is actually a bug. deferred variable expansion for a target shouldnt affect make's ability to run other targets. ___ Reply to this item at: http://savannah.gnu.org/bugs/?27714 ___ 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 #27714] expansion of $(shell) in target forces serialization of targets
URL: http://savannah.gnu.org/bugs/?27714 Summary: expansion of $(shell) in target forces serialization of targets Project: make Submitted by: vapier Submitted on: Fri 16 Oct 2009 07:50:48 AM GMT Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 3.81 Operating System: POSIX-Based Fixed Release: None Triage Status: None ___ Details: i noticed a package recently that would build serially even when i gave it -j (on a quad machine). looking into it, the reason was that $(shell) was appended to a compiler flag leading to it being expanded when the target was run: CFLAGS += $(shell .) forcing the $(shell) to be evaluated immediately allowed things to build in parallel: SOME_CHECK := $(shell .) CFLAGS += $(SOME_CHECK) behavior is seen with make-3.80 and make-3.81 here is a simple example: $ cat makefile t = 0 a b c 1 d e f 2 g h i 3 j k l 4 m n o 5 p q r 6 all: $(t) @echo $(t): @printf $@ $(shell :) $ while make -f makefile -j ; do : ; done 0abc1de2ghi3jkl4mno5pqr6 0abc1de2ghi3jkl4mno5pqr6 0abc1de2ghi3jkl4mno5pqr6 0abc1de2ghi3jkl4mno5pqr6 0abc1de2ghi3jkl4mno5pqr6 0abc1de2ghi3jkl4mno5pqr6 0abc1de2ghi3jkl4mno5pqr6 0abc1de2ghi3jkl4mno5pqr6 0abc1de2ghi3jkl4mno5pqr6 0abc1de2ghi3jkl4mno5pqr6 0abc1de2ghi3jkl4mno5pqr6 removing the $(shell :) allows for parallel evaluation: 0abc1de2gi3hjkl4mnoqr56p 0abc1de2ghi3jkl4mn5pqor6 0acde21gbhi3jkl4mno5pqr6 0abc1de2ghi3jkl4mn5qr6po 0abc1d2gehi3jkl4o5mpnqr6 0abc1de2ghi3jkl4mno5pq6r 0abc1de2ghi3jkl4mno5pqr6 0abc1de2ghi3jl4n5pkqorm6 0abc1de2ghi3jkl4mno5pqr6 0abc1de2ghi3jkl4mnpqor56 ___ Reply to this item at: http://savannah.gnu.org/bugs/?27714 ___ 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
Re: [bug #27714] expansion of $(shell) in target forces serialization of targets
On Fri, Oct 16, 2009 at 4:34 AM, Paul D. Smith invalid.nore...@gnu.org wrote: ... But before it can invoke the recipe it has to expand all the variables and functions. I had to ponder that requirement for a bit before it occurred to me that doing otherwise would either make $(eval) pointless in recipes or make it an incredible, royal pain to implement. Ditto for $(error). Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
