Re: SUN make and gcc 3.0: committed changes to branch

[Stephen M. Webb <stephen at bregmasoft dot com>]

On Thu, 31 May 2001, Phil Edwards wrote:
> On Thu, May 31, 2001 at 04:28:11PM -0400, Stephen M. Webb wrote:
> > On Thu, 31 May 2001, Phil Edwards wrote:
> > > 
> > > Constructing the header install rules by hand is evil.  (This we all know.)
> > 
> > Why is it so evil, if it does the job when nothing else seems to?
> 
> It's fragile and easy to get wrong.  We've been moving away from that,
> not towards it (I hope).
> 
> Most of the fragility and easy-to-get-wrongness would be elided, I think,
> if we did some kind of pre-install header tree, as you suggested, during
> configuration.  Maybe just copy/link everything into the build dir, and then
> "installation" is just a recursive copy.

Doing it at configuration time is wrong because it short-circuits make
dependency checks and having to reconfigure and remake after every one
line header change is unacceptable, at least on the machines I use.

Automake can't cope at all with some of the stuff that I've been encountering
with built headers, because you just can't know in advance what headers or
even what your directory structure will look like.  The only solution is a
recursive copy of all headers from a build dir that matches the install dir.
If you're doing it any way, do it for all the headers (the zero one infinity
rule) and all those complex dependency rules disappear.

There is no way to get the shadow headers or the Solaris 8 style headers to
work without going the copy route because in both cases headers get built to
match the existing, nonpredetermined, structure.

Automake is also incapable of coping with subdirectories and figuring out
header dependencies.

On Thu, 31 May 2001, Benjamin Kosnik wrote:
> 
> The automake rules should do the right thing, IMHO. It's hard to argue 
> for correct automake usage in the libstdc++-v3 install routines if these 
> very routines then don't work....
> 
> Assuming automake worked correctly, it would be nice to get rid of this 
> as extra cruft in the v3 Makefiles.

But until automake can do the right thing, I'd like to point out that the
include/Makefile.am patch I posted actually removes most of the
gmake-specific stuff.

Stephen M. webb