Re: [PATCH, v3] Fix stamp rules in libstdc++-v3/include (was: bootstrap failure on powerpc-linux)

[Benjamin Kosnik <bkoz at redhat dot com>]

> Yep, your tree probably was up to date.  In this case, the build
> failure is actually due to broken make rules in
> libstdc++-v3/include/Makefile.am.

Sigh. 
 
> Assume you have an up to date build tree.  You then add another file
> to ${std_headers} (as happened in your case, due to 'svn up').  Then,
> stamp-std is out of date wrt. the new file, but the rule as it is
> doesn't update the links, because the stamp-std file already exists:
> 
> | stamp-std: ${std_headers}
> [...]
> | 	if [ ! -f stamp-std ]; then \
> | 	  (cd ${std_builddir} && $(LN_S) $? . || true) ;\
> | 	fi ;\
> 
> Worse even, on a system where LN_S is 'cp -p', the rule doesn't cause
> updated headers to propagate to the build tree.
> 
> The patch below fixes these two issues.  It also simplifies most stamp
> rules a bit more by using separate commands.  Here, calling 'mkdir -p'
> unconditionally is actually as efficient as testing for directory
> presence first: the mkdir command line contains no shell special
> characters, which enables GNU make to directly exec mkdir, bypassing
> the shell.

Sounds good.
 
> The patch will cause warnings from 'ln -s' upon rebuild whenever the
> respective headers in the source tree have changed (I assume this
> was the reason for writing the rules the awkward way they were).

These rules are very complex, I agree. Several rules have incorrect
(missing) dependencies. The reason for the complexity, from what I
remember, is that two things are being attempted that are out of the
ordinary:

1) "staged" includes, where the build directory tries to emulate the
install directory layout. This seems like a good idea to me.

2) include files w/o extensions (.h)

I've tried to replace these with the more typical autotools include
methods in the past but something odd always messed up. Sorry, the
details are fuzzy, but hopefully this helps.

I've never been super pleased with the way this works.

:(

> This could be "fixed" by either 2>/dev/null (ugly!) or checking for
> a $(LN_S_F) in configure.ac so the noise is confined to a few old
> systems with an ln that does not grok -s.  Should I do that?

Yes.

> 
> Note that we ignore failure of 'mkdir -p' on purpose, as creating the
> directory may have failed due to a parallel make on a system where
> 'mkdir -p' is not parallel-safe.  (An alternative would be to use
> $(mkinstalldirs) but that would currently be slower on all non-GNU
> systems.)  (BTW, with BSD make, the previous code could have barfed
> out due to its implicit `set -e' when such a race were won.)

If you can do whatever toplevel or other libraries (libgomp) do, do
that.
 
> I removed one outdated comment which was introduced with
> <http://gcc.gnu.org/ml/gcc-cvs/2002-01/msg00351.html> but doesn't any
> longer match the code.
> 
> Note that the patch below does not fix the stamp-pb rule; it has more
> problems.  For fixing it, I'd like to first know whether I may assume
> GNU make for this file or whether libstdc++-v3 intends to be buildable
> with other make implementations as well?

Prerequisites say assume GNU make. See:
http://gcc.gnu.org/install/prerequisites.html

So, I think you can proceed assuming GNU make will be used.

best,
-benjamin