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

[Alexandre Oliva <aoliva@redhat.com>]

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?

> You mean, like any config.status from any day before today? :)  Yes,
> that's what I meant.

Sorry, it took me that long to figure out that's what you meant

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer