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)
- From: Michael Elizabeth Chastain <mec at shout dot net>
- To: aoliva at redhat dot com
- Cc: binutils at sources dot redhat dot com, dj at delorie dot com, drow at mvista dot com, gcc-patches at gcc dot gnu dot org, gdb-patches at sources dot redhat dot com
- Date: Sun, 29 Dec 2002 00:42:09 -0600
- Subject: Re: (toplevel) Fix dramatic breakage for ordinary crosses (related to program_transform_name)
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