This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: (toplevel) Fix dramatic breakage for ordinary crosses (related to program_transform_name)
On Sat, Dec 28, 2002 at 04:34:38PM -0200, Alexandre Oliva wrote:
> On Dec 28, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
>
> > It's a question of whether you can do the locking without making people
> > throw up, I think.
>
> I'm confident I can, but... On second thought, it occurs to me that
> all locking would accomplish is let one make in a make -j pool run one
> configure script while other makes block on the lock. Not good...
>
> Another idea is that we could really run multiple configure scripts in
> parallel, giving each one a separate cache file. We'd still have to
> synchronize the actions of taking a copy of config.cache and of
> updating it, and then we might get some tests run more than once in
> separate directories.
>
>
> But then, frankly... If running configure scripts in parallel is so
> much of a problem, why haven't we had problems so far? It's not like
> our build infrastructure has ever prevented configure scripts in
> sibling directories from running in parallel. It's perfectly possible
> for say gas, ld and binutils to be reconfigured in parallel after
> their configure scripts are modified, and I've never heard of anyone
> having problems because of this.
>
> So, if we really can't avoid the problem, is it really worth fussing
> so much about it? I mean, if you want to make absolutely sure that
> configure to be run sequentially, run `make configure' without -j and
> be done with it, and only then run `make -jN all NOTPARALLEL=all'. If
> you can live with a little bit of risk, skip `make configure' and let
> us know if you run into problems (after forced serialization of
> configure is taken out, of course :-) Comments?
Now you're speaking my language. This even lets me say "make
configure-gdb" to configure exactly the directories I need. Sure, some
reconfigures may end up taking place in parallel; I posit that if we
see a config.cache problem then it should be solved by fixing
_autoconf_ to update the cache atomically.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer