Re: Regression caused by Commit: 5bd7ad2b225b ("Preserve the real value of -jN in MAKEFLAGS using jobserver.")

2017-10-31 Thread Eric Melski
al build). It's not a common scenario, to be sure, but I have encountered this "in the wild". Just last week I worked with a large commercial build which exhibited this behavior, due to a missing dependency between the reader and

Re: Using hash instead of timestamps to check for changes.

2015-04-11 Thread Eric Melski
On 04/11/2015 08:38 AM, Enrico Weigelt, metux IT consult wrote: On 07.04.2015 00:17, Eric Melski wrote: Hi, This problem is relatively common when using an SCM system that preserves *checkin* time on files rather than *checkout* time. I'd consider that a misbehavious of the SCM

Re: Using hash instead of timestamps to check for changes.

2015-04-06 Thread Eric Melski
h that we added a feature to Electric Make called the "ledger" expressly to allow us to notice this type of out-of-dateness. Regards, Eric Melski Chief Architect Electric Cloud, Inc. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

Re: Patch to allow make to load plugins that add new functions.

2012-04-10 Thread Eric Melski
something that would work for both gmake and emake we would have to abstract away this difference -- for example, rather than directly accessing data structures, we would define a set of API's for the various operations that are needed during expansion. So there's definitely inter

Re: Prioritizing non-dependent targets in parallel make

2010-08-23 Thread Eric Melski
Eric Melski wrote: ElectricAccelerator doesn't factor runtimes into scheduling decisions, although we have talked about doing so in the past. I spent some time investigating the possibility, most recently a couple years ago. ... I ran the simulation on a variety of real-world b

Re: insufficient debug info from gnu-make

2010-08-09 Thread Eric Melski
escribe. Best regards, Eric Melski Electric Cloud, Inc. http://blog.electric-cloud.com/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make

Re: [RFC]serialize the output of parallel make?

2010-08-04 Thread Eric Melski
s the same as that used by the talon shell wrapper described elsewhere in this thread. Best regards, Eric Melski Architect Electric Cloud, Inc. http://blog.electric-cloud.com/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/ma

Re: Fwd: [RFC]serialize the output of parallel make?

2010-08-03 Thread Eric Melski
ck: http://blog.electric-cloud.com/2008/12/01/untangling-parallel-build-logs/ You can read more about Accelerator on the blog, or here: http://www.electric-cloud.com/products/electricaccelerator.php Eric Melski Architect Electric Cloud, Inc. http://blog.electric

Re: Fwd: [RFC]serialize the output of parallel make?

2010-08-03 Thread Eric Melski
ck: http://blog.electric-cloud.com/2008/12/01/untangling-parallel-build-logs/ You can read more about Accelerator on the blog, or here: http://www.electric-cloud.com/products/electricaccelerator.php Eric Melski Architect Electric Cloud, Inc. http://blog.electric

Re: Prioritizing non-dependent targets in parallel make

2010-01-05 Thread Eric Melski
al link, which is of course much longer. But then -- of course -- that can't start until all the other jobs are done anyway, so the fancy scheduling doesn't help. I'll see if I can dig up the patch for ElectricInsight and maybe write it up in a blog. up that code, and maybe wri

Re: Prioritizing non-dependent targets in parallel make

2010-01-04 Thread Eric Melski
al link, which is of course much longer. But then -- of course -- that can't start until all the other jobs are done anyway, so the fancy scheduling doesn't help. I'll see if I can dig up the patch for ElectricInsight and maybe write it up in a blog. up that code, and maybe wri

Re: Prioritizing non-dependent targets in parallel make

2010-01-04 Thread Eric Melski
table exception is the final link, which is of course much longer. But then -- of course -- that can't start until all the other jobs are done anyway, so the fancy scheduling doesn't help. I'll see if I can dig up the patch for ElectricInsight and maybe write it up in a blog.