Re: (toplevel) Fix dramatic breakage for ordinary crosses (related to program_transform_name)

[Daniel Jacobowitz <drow@mvista.com>]

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