Time to update documentation regarding supported configuration styles?

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In the interest of full disclosure: It is my current intention to let
this problem remain (since I don't know how to fix it with a minimal
time investment) until after the freeze on the 3.3 branch for
non-documentation patches and then propose my dreaded (by some)
documentation patch, which clearly states the only really supported
configuration style by the developer masses.  If you are the type that
disliked that documentation patch, then consider this fair warning of
my full future intentions (since it is absolutely not fair to users to
document that things "should work", "usually work" when we know they don't).

FYI, (GNU) `make install' after bootstrap where srcdir == objdir is
currently broken on both the gcc-3_3-branch and the mainline.  There
was a time when the installed trees for that configuration verses the
srcdir != objdir configuration were file-for-file identical (although
not byte-for-byte due to timestamps and subtle path differences, etc)
for all gcc subsystems (save ada which is not exercised by my daily
bootstraps, thus I have no info).  It was stated that would remain
true and was indeed a condition for removing various strong statements
I added in the documentation regarding the only truly supported
configuration styles.

Here is the current failure (possibly masking others since all of
libjava is left to be installed after libffi):

gmake[3]: Entering directory `.../<target-triple>/libffi/include'
gmake[3]: Nothing to be done for `install-exec-am'.
/bin/sh ../../mkinstalldirs /home/ljrittle/tmp-ref5/install-ref5/include
../../mkinstalldirs: Can't open ../../mkinstalldirs: No such file or directory
gmake[3]: *** [install-hackDATA] Error 2

This is what is getting into libffi/include/Makefile when srcdir == objdir:

top_srcdir = ..
mkinstalldirs = $(SHELL) $(top_srcdir)/../mkinstalldirs

yielding mkinstalldirs = /bin/sh ../../mkinstalldirs
when it must be ../../.. in this case (at least, for multilib ports).

A reasonable absolute path is getting into top_srcdir when srcdir != objdir.

However, this is a red herring, since it appears the introduction of
this install error is related to something external to that file.
BTW, I estimate that this has been broken for months now thus
strengthening my usual claim that *no* active developers care about
this and that we'd be better off changing the documentation but I
can't give the exact patch or date of introduction; things have been
churning too much and the machines that should have spotted this
problem ASAP have been broken for other reasons until recently.  Nor
is the onus on me to find the exact patch in order to implement my
renewed favored fix to the problem... ;-)

I have at least two other, known to me, previously posted issues
(sometimes with patches, that have never been rejected or approved)
related to the gcc-3_3 branch and/or mainline that will, in my
opinion, also cause documentation changes close to the release of 3.3
and/or 3.4 respectively if no fixes are forthcoming.  Sorry, but I'm
basically past my time limit on dealing with the complexity of the
rapid churn in the Makefile infrastructure especially with no feedback
and thus I'm throwing in the towel on attempting to support obscure
yet documented as "working" configuration styles and make
implementations (the subject of the other issues I know about).

(BTW, I want to be quite clear: no offense to anyone doing that work
 and I fully support it but I hereby suggest again that it would be
 great if the people making *basic* reorganization and changes to the
 build infrastructure would actually test the multiple configuration
 styles we purport to support.)

Thanks,
Loren