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

Daniel Jacobowitz drow@mvista.com
Sat Dec 28 09:58:00 GMT 2002


On Sat, Dec 28, 2002 at 03:51:19PM -0200, Alexandre Oliva wrote:
> On Dec 28, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
> 
> > I notice that you moved the .NOTPARALLEL down to the configure section. 
> 
> Just because otherwise `make NOTPARALLEL=something' would cause make
> to try to build something, not all.
> 
> > While it is there what do you think of removing the serialization
> > dependencies?
> 
> Some day, some day...
> 
> Really, the only way to avoid them is to introduce some form of
> locking, an idea that DJ vehemently rejects.
> 
> Unless...  We could perhaps have NOTPARALLEL set by default, which
> would take care of avoiding configurations in parallel even without
> serialized dependencies, but a configure option to disable NOTPARALLEL
> and introduce locking.  DJ, how does this sound for you?

It's a question of whether you can do the locking without making people
throw up, I think.

> > Also, top level configure no longer accepts --norecursion.
> 
> The autoconf spelling is --no-recursion.  Anyway, it no longer
> recurses...  Unfortunately, with autoconf, it gets *really* tricky to
> introduce options that are not in the autoconf option space (--with or
> --enable), so offering --norecursion for backward-compatibility gets
> tricky.
> 
> > This means that one has to configure from scratch in any existing
> > working directory.
> 
> ./config.status --recheck?
> 
> 
> Oh, perhaps you mean with a config.status that pre-dates
> autoconfiscation?  Yeah, this would be tricky...  Editing
> config.status is your best bet.  Failing that, well...  Running the
> top-level configure again is no such big deal, is it? :-)

You mean, like any config.status from any day before today? :)  Yes,
that's what I meant.  At least we get an error message.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer



More information about the Gcc-patches mailing list