[bug #49014] Zombies in parallel builds with pselect code

2017-06-22 Thread Matt Whitlock
Follow-up Comment #16, bug #49014 (project make): I have built several large software suites (including KDE Frameworks and Plasma Workspaces) since applying this patch, and I have not seen the zombie problem recur. ___ Reply to this item

[bug #51190] make -n does not show exported variables

2017-06-22 Thread Paul D. Smith
Update of bug #51190 (project make): Summary: make -n fails if export is used with recursion => make -n does not show exported variables ___ Reply to this item at:

Re: Unlink failure on abort

2017-06-22 Thread Paul Smith
On Tue, 2017-06-20 at 18:20 +0300, Eli Zaretskii wrote: > > Date: Sun, 18 Jun 2017 17:42:51 +0300 > > From: Eli Zaretskii > > Cc: alex...@gmail.com, bug-make@gnu.org > > > I think the problem is that reap_children() is called after > > > delete_child_targets, so the child jobs can

[bug #51292] Handling make rules where prerequisites are determined by functions for specific targets lists

2017-06-22 Thread Markus Elfring
Follow-up Comment #3, bug #51292 (project make): Another example by Mike Gran: demo: $(guile (root->list-of-objects "demo")) $(CC) $(LDFLAGS) -o $@ $^ You showed an other interesting use case. It seems that only simple input file dependencies would be constructed. I guess that the

Re: How to avoid the double execution of a make info call?

2017-06-22 Thread SF Markus Elfring
> If the makefile, or any of the files it includes, is updated by make > then make will re-execute itself and re-read all the makefiles from > scratch so it can see the updated content. When that happens, > obviously all the $(info ...) functions etc. will be re-expanded. Thanks for your

[bug #49014] Zombies in parallel builds with pselect code

2017-06-22 Thread Martin Dorey
Follow-up Comment #15, bug #49014 (project make): I've been running with the git head as of your 2017-06-04 request. The problem hasn't recurred for me. I don't think that means as much as it would have a few months ago because I've had less cause to run my

[bug #51292] Handling make rules where prerequisites are determined by functions for specific targets lists

2017-06-22 Thread Mike Gran
Follow-up Comment #2, bug #51292 (project make): Is this what you mean? CFLAGS = -g -O2 -Wall all: demo define GCOMP2 (define (root->list-of-objects target) (list (string-append target "_foo.o") (string-append target "_bar.o"))) #f endef $(guile $(GCOMP2)) demo: $(guile

Re: How to avoid the double execution of a make info call?

2017-06-22 Thread Paul Smith
On Thu, 2017-06-22 at 15:56 +0200, SF Markus Elfring wrote: > > As always, if you can't figure out what's going on running "make > > -d" will help you more than we can. > > I wonder about the information “Re-executing[1]: make --no-builtin- > rules -d” there. > Unfortunately, I do not recognise

[bug #51292] Handling make rules where prerequisites are determined by functions for specific targets lists

2017-06-22 Thread Markus Elfring
Follow-up Comment #1, bug #51292 (project make): Example by Mike Gran: $(objects): $(foreach X,$@,\ $(guile (gcomp "$(X)"))) @true I would like to see a kind of function call for the specification of prerequisites (instead of the shown function calls in the recipe). A

[bug #51292] Handling make rules where prerequisites are determined by functions for specific targets lists

2017-06-22 Thread Mike Gran
Additional Item Attachment, bug #51292 (project make): File name: makefile Size:0 KB File name: gcomp.scm Size:0 KB ___ Reply to this item at:

Re: How to avoid the double execution of a make info call?

2017-06-22 Thread SF Markus Elfring
> Your Makefile looks likely to rebuild .depend, a file that it includes. > So, like Paul said: >>> or else make has re-executed itself >>> because this makefile or one of its >>> included files was rebuilt; Yes. - This can happen at the moment. > I wonder about the information

Re: How to avoid the double execution of a make info call?

2017-06-22 Thread SF Markus Elfring
> If you are seeing these values printed multiple times it means that the > makefile is being parsed multiple times. How can such additional parsing be clarified further? Will it help to display extra data from special make variables? > Why that might be, we can't determine from the

[bug #51292] Handling make rules where prerequisites are determined by functions for specific targets lists

2017-06-22 Thread Markus Elfring
URL: Summary: Handling make rules where prerequisites are determined by functions for specific targets lists Project: make Submitted by: elfring Submitted on: Thu 22 Jun 2017 03:10:13 PM CEST

Re: [bug #49844] 'make -j' without explicit process count sometimes doesn't parallelize

2017-06-22 Thread Sven C. Dack
Hello Paul, I was thinking of "--", but didn't test it, because it isn't being mentioned in the man page nor in the info page. Cheers On 22/06/17 13:10, Paul Smith wrote: On Thu, 2017-06-22 at 13:01 +0100, Sven C. Dack wrote: You either have to restrict the number of jobs by giving an

[bug #49014] Zombies in parallel builds with pselect code

2017-06-22 Thread Paul D. Smith
Follow-up Comment #14, bug #49014 (project make): Any updates on this? Have you seen the pselect() zombie issue re-appear after applying the patch? Thanks for testing! ___ Reply to this item at:

[bug #49844] 'make -j' without explicit process count sometimes doesn't parallelize

2017-06-22 Thread Paul D. Smith
Update of bug #49844 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: Even simpler is to

Re: [bug #49844] 'make -j' without explicit process count sometimes doesn't parallelize

2017-06-22 Thread Paul Smith
On Thu, 2017-06-22 at 13:01 +0100, Sven C. Dack wrote: > You either have to restrict the number of jobs by giving an explicit > count or by limiting it with a load average ( -l option) or use > non-numerical make targets such as "t1 t2 t3 ..." or simply add another > flag after -j to make. > $

Re: [bug #49844] 'make -j' without explicit process count sometimes doesn't parallelize

2017-06-22 Thread Sven C. Dack
Hello, this isn't a bug, but it's how the -j option works. From the manual: -j [jobs], --jobs[=jobs] Specifies the number of jobs (commands) to run simultaneously. If there is more than one -j option, the last one is effective. If the -j option

Re: How to avoid the double execution of a make info call?

2017-06-22 Thread Paul Smith
On Thu, 2017-06-22 at 09:36 +0200, SF Markus Elfring wrote: > > modules_without_mli::=$(filter-out $(basename $(mli_sources)),$(basename > > $(ml_sources))) > > $(info modules_without_mli) > > $(info $(sort $(modules_without_mli))) > > Now I observe that the test output occurs twice while I am

Re: How to avoid the double execution of a make info call?

2017-06-22 Thread SF Markus Elfring
> modules_without_mli::=$(filter-out $(basename $(mli_sources)),$(basename > $(ml_sources))) > $(info modules_without_mli) > $(info $(sort $(modules_without_mli))) It seems that I got this design approach working to some degree by the addition of a few calls of make functions. I am not