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

[Michael Elizabeth Chastain <mec@shout.net>]

Alexandre Oliva writes:
> Should we penalize everybody just because some might want to make -j
> and make it absolutely sure that they won't have any risk whatsoever
> of cache corruption and they won't miss any opportunities for caching
> test results.

In my humble opinion, yes.  If you have a choice of options,
make the default option be safe, and let people who want to go faster
with risk of corruption specify additional options.

Perhaps you think of "make -j" as an inherently unsafe option.
In 1999 I would have agreed.  In 2002 I think it's debatable.
As time passes, I think it will become more and more important
that it work without races.

I build gcc about 50 times per week with automated scripts.  Right now
I use a single-processor machine.  If I buy a multi-processor machine,
I would like to just turn on "make -j" and have it work.  When it doesn't
work, I want all the bugs that I see to be real bugs that I can report
to gcc-bugs and not have to check for cache corruption on every fail and
not have people closing my bug reports with "might be cache corruption,
don't use -j".

I know other people run automated and semi-automated builds, too.

> Couldn't we instead ask these to pass an argument to configure such that
> will make sure their requirements are satisfied, while optimizing for
> most who aren't doing parallel builds, or can take the negligible risk of
> cache corruption, or don't care about potential loss of sharing of cache
> results, but who want to benefit from the ability to configure only the
> packages that matter for them.  Are we really doing the right trade off?

I agree that this is a trade-off.  Obviously we disagree about what the
right trade-off is.

I think I've aired my viewpoint enough (it's kind of a simple view)
so I'll rest here.

Michael C