From: DJ Delorie <dj@delorie.com>
To: aoliva@redhat.com
Cc: drow@mvista.com, gcc-patches@gcc.gnu.org,
gdb-patches@sources.redhat.com, binutils@sources.redhat.com
Subject: Re: (toplevel) Fix dramatic breakage for ordinary crosses (related to program_transform_name)
Date: Sat, 28 Dec 2002 10:49:00 -0000 [thread overview]
Message-ID: <200212281846.gBSIkLP07491@envy.delorie.com> (raw)
In-Reply-To: <or8yya58x4.fsf@free.redhat.lsd.ic.unicamp.br> (message from Alexandre Oliva on 28 Dec 2002 15:51:19 -0200)
> Unless... We could perhaps have NOTPARALLEL set by default, which
> would take care of avoiding configurations in parallel even without
> serialized dependencies, but a configure option to disable NOTPARALLEL
> and introduce locking. DJ, how does this sound for you?
I am not "vehemently" opposed to it. I've just seen, through
experience, that there are lots of ways for it to go wrong.
Serialized dependencies is a lot simpler and less error-prone (once we
get them right, nobody's commented on my last suggestion). If we had
a simple locking mechanism that worked on all the
ext/nfs/dos/samba/etc/distcc filesystems we need to support, I'd be OK
with it. I just think that people underestimate how much effort it
takes to do locking reliably.
The problem with NOTPARALLEL is that it shuts of *ALL* the toplevel
parallelisms, including building A while configuring B, and testing in
parallel. The toplevel Makefile really needs to allow parallel jobs
to take advantage of the work we've done. We just need to be able to
identify the parts that can't be done simultaneously, and somehow
prevent those.
next prev parent reply other threads:[~2002-12-28 18:46 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-28 4:36 Nathanael Nerode
2002-12-28 8:33 ` Alexandre Oliva
2002-12-28 9:51 ` Daniel Jacobowitz
2002-12-28 9:56 ` Alexandre Oliva
2002-12-28 9:59 ` Daniel Jacobowitz
2002-12-28 10:41 ` Alexandre Oliva
2002-12-28 10:46 ` Dan Kegel
2002-12-28 11:07 ` DJ Delorie
2002-12-28 12:26 ` Daniel Jacobowitz
2002-12-28 10:50 ` Daniel Jacobowitz
2002-12-28 11:01 ` DJ Delorie
2002-12-28 12:57 ` Alexandre Oliva
2002-12-28 13:51 ` Alexandre Oliva
2002-12-29 18:57 ` Alexandre Oliva
2002-12-28 14:14 ` DJ Delorie
2002-12-28 15:22 ` Alexandre Oliva
2002-12-28 10:54 ` Alexandre Oliva
2002-12-28 10:49 ` DJ Delorie [this message]
2002-12-28 11:00 ` DJ Delorie
-- strict thread matches above, loose matches on Subject: below --
2003-01-06 0:49 Michael Elizabeth Chastain
2002-12-29 0:39 Michael Elizabeth Chastain
2002-12-29 2:48 ` Alexandre Oliva
2002-12-28 13:22 Michael Elizabeth Chastain
2002-12-28 13:44 ` Alexandre Oliva
2003-01-06 0:04 ` Ben Elliston
2002-12-28 1:00 Nathanael Nerode
2002-12-28 1:22 ` Alexandre Oliva
2002-12-28 1:33 ` Alexandre Oliva
2002-12-28 7:47 ` Kazu Hirata
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200212281846.gBSIkLP07491@envy.delorie.com \
--to=dj@delorie.com \
--cc=aoliva@redhat.com \
--cc=binutils@sources.redhat.com \
--cc=drow@mvista.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox