On May 15, 2013, Jason Merrill wrote:
> + elif [ $count == 300 ]; then
s/==/=/
Ok with this change.
Thanks,
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America
On May 15, 2013, at 10:30 AM, Jason Merrill wrote:
> In my testing, bash seems to consistently run the 0 trap when it exits due to
> a signal; are there other shells that don't?
trap 0 is for every exit case, normal, error, abnormal. This is why you'd see
two removals if you used 0 and any oth
On 05/15/2013 03:51 AM, Alexandre Oliva wrote:
I borrowed the general approach from libtool's shell locking machinery.
I suppose it might be the case that lock files (in libtool's case) get
removed twice, but I'm pretty sure there was broad portability testing
in the process that led to that cons
Alexandre Oliva writes:
> constructs as 'rm ; (exit $status); exit', but I won't even pretend
> to recall the rationale for that ;-)
See the autoconf manual.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And
On May 14, 2013, Jason Merrill wrote:
>> trap 'rmdir "$lockdir"; exit $status' 0 1 2 15
> In my testing I found that trapping signals other than 0 resulted in
> trying to rmdir twice if the process is interrupted.
Interesting... I guess it's one for the signal and one for the exit...
I borrow
On May 14, 2013, at 1:46 PM, Jason Merrill wrote:
> On 05/14/2013 02:04 PM, Mike Stump wrote:
>> I worry about quoting.
>
> In my experience, "$@" does fine for passing on arguments.
:-) It used to require ${0+"$@"}, but later shells fixed the edge case to make
"$@" work nicely. While I'll st
On 05/14/2013 02:04 PM, Mike Stump wrote:
I worry about quoting.
In my experience, "$@" does fine for passing on arguments.
Jason
On 05/14/2013 01:24 PM, Tom Tromey wrote:
It seems to me you can get the desired functionality in the Makefiles
using order-only dependencies -- just force some ordering of the
targets.
Order dependencies are the wrong solution: for one thing, they don't
allow for building just a single front
On May 13, 2013, at 9:49 PM, Alexandre Oliva wrote:
> However, rather than implementing the locking in Makefiles, I'm thinking
> it might be wiser to do so in a script that takes the lock name and the
> command to run while holding the lock.
I worry about quoting. Anytime you accept and pass on
> "Alexandre" == Alexandre Oliva writes:
Alexandre> However, rather than implementing the locking in Makefiles,
Alexandre> I'm thinking it might be wiser to do so in a script that
Alexandre> takes the lock name and the command to run while holding the
Alexandre> lock.
It seems to me you can
On 05/14/2013 12:49 AM, Alexandre Oliva wrote:
However, rather than implementing the locking in Makefiles, I'm thinking
it might be wiser to do so in a script that takes the lock name and the
command to run while holding the lock.
Good point.
trap 'rmdir "$lockdir"; exit $status' 0 1 2 15
I
On May 9, 2013, Jason Merrill wrote:
> On 05/01/2013 07:40 PM, Mike Stump wrote:
>> $ bash -c "trap 'echo remove lock' 0; true"; echo $?
> Thanks for the suggestion. Here's a revised patch:
I like the idea of the patch, for I feel your pain too ;-)
However, rather than implementing the locki
On May 8, 2013, at 8:59 PM, Jason Merrill wrote:
> Thanks for the suggestion. Here's a revised patch:
Nice. I too see a whole machine style lock up on linux (openSUSE 11.4) and my
machine has 12G and 8*2 cores. I just ignore it and wait patiently for the
storm to pass, but, it is annoying.
On 05/01/2013 07:40 PM, Mike Stump wrote:
$ bash -c "trap 'echo remove lock' 0; true"; echo $?
Thanks for the suggestion. Here's a revised patch:
commit 79b52becc6a8649933f7442d46e8054f8b6abd4b
Author: Jason Merrill
Date: Thu Apr 25 17:54:17 2013 -0400
* Makefile.in (link-mutex, re
On 06/05/2013 17:41, Jason Merrill wrote:
> On 05/05/2013 09:57 AM, Dave Korn wrote:
>> This sounds like a bad idea to me, and not just because the locking
>> mechanism is dodgy. Is the problem more widespread than just your laptop?
>> Does it affect other host OSs? Linking multiple frontends at
On 05/05/2013 09:57 AM, Dave Korn wrote:
This sounds like a bad idea to me, and not just because the locking
mechanism is dodgy. Is the problem more widespread than just your laptop?
Does it affect other host OSs? Linking multiple frontends at once doesn't
lock up my desktop PC, so I'd rathe
On 01/05/2013 03:02, Jason Merrill wrote:
> Since GNU Make doesn't support anything like the .MUTEX directive
> (http://savannah.gnu.org/bugs/?func=detailitem&item_id=17873), and
> accidentally doing "make -j8 -l4" makes my laptop useless for several
> minutes while it tries to link all the front e
On Apr 30, 2013, at 7:02 PM, Jason Merrill wrote:
> Releasing the lock is not reliable; if the user interrupts the link with ^C,
> the lock will remain. So I adjusted 'make all' to remove the lock early on,
> though that only works for the typical case, and users that do something like
> 'make
Since GNU Make doesn't support anything like the .MUTEX directive
(http://savannah.gnu.org/bugs/?func=detailitem&item_id=17873), and
accidentally doing "make -j8 -l4" makes my laptop useless for several
minutes while it tries to link all the front ends at once, I decided to
kludge a workaround.
19 matches
Mail list logo
