Re: [PATCH] Fix srcdir=. bug in build modules

[Paolo Bonzini <bonzini at gnu dot org>]

> It should not [need to] build a symlink tree for libiberty.  Libiberty
> was modified some while back to work properly when there's a build in
> its srcdir.

Indeed it does work.  libcpp does as well.

It may be interesting to see under which condition automake fails, maybe 
the error can be restricted to --enable-maintainer-mode.  I'll dig the 
error message in automake's CVS repo.

> Does you patch still make sense in light of this?

Bison and other build modules may break in obscure conditions such as:
1) build-side bison is made correctly
2) ... gcc and everything else is built ...
3) host-side bison is remade correctly
4) user modifies bison's configure.ac
5) build-side bison does not reconfigure with a "source directory 
already configured" error.

I contemplated adding a Makefile.def flag saying whether a source 
directory can be configured in two different places, and only create the 
symlink tree in the other case.  But maybe it is overkill, though, when 
a safer behavior that works for all packages has already been implemented.

I can also move to configure.in the construction of the symlink-tree for 
all build packages and "include".

But in general, since this configuration is flawed, I'd be in favor of 
eliminating special cases that only make it a bit more efficient.  I 
don't care if an extra symlink tree is generated.  For example, target 
modules support symlinking in a similar way, but only if they are marked 
"stage=true": this should be set for all automakized target modules that 
are also host modules (only zlib?), but I'd rather use symlink-trees for 
all target modules when srcdir=.

It would also give the least surprise to users who wanted srcdir=. 
because then all configures are run with srcdir=.

Paolo