Hi,
Since some things happen at the same time there is no single serial
order. The semaphore mechanism, forces one of the possible orders.
I forgot to say that for recipes with multiple commands you need to
either use the new .ONESHELL target or do this kind of thing:
mytarget:mytarget:
On Tue, Aug 3, 2010 at 2:51 PM, Tim Murphy tnmur...@gmail.com wrote:
Since some things happen at the same time there is no single serial
order. The semaphore mechanism, forces one of the possible orders.
I'm not familiar with source code of make, but I believe the serial
order of shells is
Chiheng Xu wrote:
On Tue, Aug 3, 2010 at 2:51 PM, Tim Murphytnmur...@gmail.com wrote:
Since some things happen at the same time there is no single serial
order. The semaphore mechanism, forces one of the possible orders.
I'm not familiar with source code of make, but I believe the serial
Date: Tue, 3 Aug 2010 07:51:22 +0100
From: Tim Murphy tnmur...@gmail.com
Cc: e...@opera.com, bug-make@gnu.org
mytarget:
-command1
-command2
-command3
Note that I'm using bash syntax here. On windows if you want to use
cmd.exe then good luck - I don't think it's really fit for
Chiheng Xu wrote:
What I want is transparent parallel make. Make can issue multiple
shells simultaneously, but print their outputs in the same order as in
a serial make.
ElectricAccelerator is a gmake replacement that does exactly this. I
wrote about this feature a while back:
On Wed, Aug 4, 2010 at 10:41 AM, Eric Melski s...@melski.net wrote:
ElectricAccelerator is a gmake replacement that does exactly this. I wrote
about this feature a while back:
http://blog.electric-cloud.com/2008/12/01/untangling-parallel-build-logs/
You can read more about Accelerator on
Edward Welbourne wrote:
2x is too much. 1.5x has been the best in my experience, any more than that
and you're losing too much CPU to scheduling overhead instead of real work.
Any less and you're giving up too much in idle or I/O time.
This depends a bit on whether you're using icecc or some
If my guess is not wrong, the semaphore safeguard the consistency of
output of one command, not the order of commands.
well, with -j, commands are being run concurrently, so there *isn't* a
strict ordering of commands to safeguard, although output shall be
delivered in roughly the order of
2x is too much. 1.5x has been the best in my experience, any more than that
and you're losing too much CPU to scheduling overhead instead of real work.
Any less and you're giving up too much in idle or I/O time.
This depends a bit on whether you're using icecc or some similar
distributed
On Mon, Aug 2, 2010 at 4:22 PM, Edward Welbourne e...@opera.com wrote:
If my guess is not wrong, the semaphore safeguard the consistency of
output of one command, not the order of commands.
well, with -j, commands are being run concurrently, so there *isn't* a
strict ordering of commands to
-- Forwarded message --
From: Chiheng Xu chiheng...@gmail.com
Date: Fri, Jul 30, 2010 at 6:02 PM
Subject: Re: [RFC]serialize the output of parallel make?
To: Tim Murphy tnmur...@gmail.com
On Fri, Jul 30, 2010 at 5:54 PM, Tim Murphy tnmur...@gmail.com wrote:
Hi,
The cost to the
Chiheng Xu wrote:
-- Forwarded message --
From: Chiheng Xuchiheng...@gmail.com
Date: Fri, Jul 30, 2010 at 6:02 PM
Subject: Re: [RFC]serialize the output of parallel make?
To: Tim Murphytnmur...@gmail.com
On Fri, Jul 30, 2010 at 5:54 PM, Tim Murphytnmur...@gmail.com wrote:
Hi,
12 matches
Mail list logo
