PATCH: PR4082

[Loren James Rittle]

> To recap, it makes './configure; make bootstrap' work again and was
> the change implied by Alex's comments on the situation.  'make check'
> still reports more errors in libstdc++-v3 (however, none signal real
> errors).  As of what I read the other day, 'make install' is still
> known to install too many files (and perhaps other issues?).

OK, I currently see no other issues related to 'make install', only
the extra files.  Here is the exact list, as of today, of extra files
(and directories) installed from the 3.0.X branch when in-source
directory ./configure is used instead of $srcdir/configure:

$prefix/include/g++-v3/Makefile.am
$prefix/include/g++-v3/Makefile.in
$prefix/include/g++-v3/bits/c++config
$prefix/include/g++-v3/bits/concept_checks.h
$prefix/include/g++-v3/bits/container_concepts.h
$prefix/include/g++-v3/bits/limits_generic.h
$prefix/include/g++-v3/bits/sequence_concepts.h
$prefix/include/g++-v3/bits/stl_config.h
$prefix/include/g++-v3/bits/stl_iterator_base.h
$prefix/include/g++-v3/c
$prefix/include/g++-v3/c_shadow
$prefix/include/g++-v3/c_std
$prefix/include/g++-v3/ext/bvector
$prefix/include/g++-v3/ext/stl_bvector.h
$prefix/include/g++-v3/ext/tree
$prefix/include/g++-v3/std

Ahh, looks like the damage is self-contained inside one Makefile.am
but it is a bit more than just Makefile.in and Makefile.am being
installed when they should not be.  Wasn't someone already working on
a patch for this?  If no patch arrives by Friday, I might be able to
look at it then.  Otherwise, it will be next week.

In either case, I hereby commit to testing in-source directory
./configure on both mainline and the 3.0.X branch on a daily basis in
addition to what is already being run.  This way we can incrementally
fix damage as it occurs instead of waiting until the users find it. ;-)

Here is the procedure I will use:

sync source with CVS (as I currently do; ref4 tracks 3.0.X, ref5 mainline)
$srcdir/configure in fresh directory (as I currently do)
gmake bootstrap (as I currently do; on failure, stop and report to private list)
gmake check (as I currently do; e-mail report to public list)
gmake install (as I currently do)
move ${prefix} to ${prefix}-old
duptree
./configure in dup'd tree with exactly the same arguments as above
gmake bootstrap (on failure, stop and report to private list)
gmake install
diff -r ${prefix} ${prefix}-old | filter to remove expected binary differences

Results of the final difference will come in an e-mail report I
already review on a daily basis.  I will manually forward breakage
reports to avoid cluttering the public lists with yet more automatic mail.

Regards,
Loren