Re: [PATCH, v3] PR 35954: rebuild of precompiled headers

[Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>]

Hello Paolo, Benjamin,

Thanks for the reviews.

* Paolo Bonzini wrote on Fri, Apr 18, 2008 at 12:38:27PM CEST:
> Patch is okay, but first commit the other one.
>
>> <http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01103.html> which hasn't
>> been reviewed yet.
>
> Let's review this too.  The only nit I have to pick is, why can't we  
> just use $(LN_S) -f?  This is already done in other places.

Where else is '$(LN_S) -f' used?  I could not find it anywhere.
The Autoconf manual, shell portability section, mentions

|      Don't rely on `ln' having a `-f' option.

This comment was added in 1994, as part of a larger rewrite, without any
details.  I don't have access to a system with this issue, but Solaris 9
ln fails to successfully overwrite an existing symlink with -s -f, so we
may not count on the exit status.

Should I still use $(LN_S) -f?
Ignoring return value and 2>/dev/null seems safer.

* Benjamin Kosnik wrote on Fri, Apr 18, 2008 at 05:46:52PM CEST:
> 
> Can you send me links of any other unreviewed libstdc++ patches? Thanks.

[PATCH] Fix Autoconf cache variable names
<http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01050.html>
This affects libstdc++, libgomp, and libgfortran

I'm working on a patch for fixing stamp-pb along the lines of the patch
in above-mentioned msg01103.html.

* Benjamin Kosnik wrote on Fri, Apr 18, 2008 at 06:56:24PM CEST:
> 
> > I thought I reviewed this, but cannot find it in the archives. Will do
> > asap.
> 
> http://gcc.gnu.org/ml/libstdc++/2008-03/msg00083.html

Thanks.  Sorry, but I'm not subscribed to libstdc++, so I didn't see it.
In that message, you write:

> 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.

Yes, I agree in principle.

> 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.

If you can dig out proposed patches, or PRs about this, that would help.
I already gave rewriting the stuff more a shot or so, but that's still
buggy so I'm not posting it yet.

Cheers,
Ralf