Re: Checking software build tries for “commands.cmo”

> (I would guess that most of the people on the bug-make mailing list have > never worked with ocaml and therefore don't know what needs to be done to > build it.) Yesterday I realised that one source source file needed a special handling in the mentioned subdirectory. > The snippet of

RE: Checking software build tries for “commands.cmo”

> I have noticed a moment ago that an interface description file was missing > somehow for the OCaml source file in this compilation attempt. ... > I wonder then that the make tool did not give me a direct clue for a failed > software dependency as I am used to in other cases. Would you have it

Re: Checking software build tries for “commands.cmo”

On Tue, 13 Jun 2017, SF Markus Elfring wrote: > I am testing the following pattern rules with the program “GNU Make 4.2.1-1.7” > on my openSUSE Tumbleweed system as I would like to adjust some areas > in affected make scripts for another evolving software tool. > > … > %.cmi: %.mli >

Re: Are prerequisites made in deterministic order when parallelism is disabled?

On Tue, 2017-06-13 at 10:33 -0500, Brett Stahlman wrote: > I don't see anything in the Make docs that guarantees prerequisites > will be processed in left to right order. Opinions on the web seems to > be split into 2 camps: > > 1. Make always builds dependencies in left to right order, but a >

Re: Are prerequisites made in deterministic order when parallelism is disabled?

On Wed, 14 Jun 2017 11:25:35 -0400 Kyle Rose wrote: > The right answer is always to write your makefiles so the rules execute > in the required order whether run in parallel or not. Relying on > whichever arbitrary ordering GNU make employs, even if that behavior is >

Re: Checking software build tries for “commands.cmo”

> elfring@Sonne:~/Projekte/Coccinelle/20160205/commons> LANG=C make -d > commands.cmo V=1 > … > No implicit rule found for 'commands.cmo'. > Finished prerequisites of target file 'commands.cmo'. > Must remake target 'commands.cmo'. > Successfully remade target file 'commands.cmo'. > make:

Re: Are prerequisites made in deterministic order when parallelism is disabled?

The right answer is always to write your makefiles so the rules execute in the required order whether run in parallel or not. Relying on whichever arbitrary ordering GNU make employs, even if that behavior is stable (either historically or by design), is likely to result in sadness at some point,

Re: Are prerequisites made in deterministic order when parallelism is disabled?

I've been waiting for Paul to show up with the definitive word but he may be away. I'm 95% sure he's spoken on this before with the gist of it being "While not required by standard, GNU make has always worked left-to-right and this will not change". While I *think* I've correctly channeled his

[bug #51237] Deadlock in Ctrl-C handler on Windows

Follow-up Comment #1, bug #51237 (project make): Thanks for the analysis and the patch. Your patch is too large to accept without legal paperwork. Would you be willing to assign copyright for your changes to the FSF, so we could accept your contribution? If so, I can send you the legal form and

Re: Are prerequisites made in deterministic order when parallelism is disabled?

On Wed, Jun 14, 2017 at 2:00 AM, Edward Welbourne wrote: > Brett Stahlman (13 June 2017 17:33) >> I don't see anything in the Make docs that guarantees prerequisites >> will be processed in left to right order. Opinions on the web seems to >> be split into 2 camps: >> >>

[bug #51237] Deadlock in Ctrl-C handler on Windows

URL: Summary: Deadlock in Ctrl-C handler on Windows Project: make Submitted by: mbuilov Submitted on: Wed 14 Jun 2017 12:43:28 PM UTC Severity: 3 - Normal Item Group:

Re: Are prerequisites made in deterministic order when parallelism is disabled?

Brett Stahlman (13 June 2017 17:33) > I don't see anything in the Make docs that guarantees prerequisites > will be processed in left to right order. Opinions on the web seems to > be split into 2 camps: > > 1. Make always builds dependencies in left to right order, but a >well-designed