Re: Proposed header changes (for the trunk)

[Benjamin Kosnik <bkoz at redhat dot com>]

> My motivation is this.  The current header situation is a bit of a mess, with a
> whole lot of configury and makefile magic just to get the right bits picked
> up during the build and later installed.  Recently I had to do some
> side-by-side cross compiler installations, and found the installed headers
> don't really play very nicely (nothing broke, but it could have).  The c_std
> headers aren't anywhere near standards compliant, the c headers are
> incomplete (and inappropriate) and the c_shadow headers are in a swamp.

Ok.

> (1) Realign the build process so all headers are "built."  That is, after
> configuration but before the rest of the libstdc++ software gets built, all
> the required headers are either copied to or created in the build tree
> in a structure that matches the install tree.  All the rules to build the
> headers are localized in the include/Makefile.am file rather than spread
> out across acinclude.m4, configure.in, src/Makefile.am, and a few other
> places.  There would be greater decoupling and improved consistency.

I like the include/Makefile.am, but I never got it to work very well with 
subdirs (ie include/bits, include/std). It's very possible that I was 
just doing something wrong, so I'm interested in seeing what you did if 
it's working for you.

In theory, this is good. 

> I have a patch for this (almost) ready to go.  Bootstrap turnaround time here 
> can sometimes be measured in days, but so far it works.  Say the word and I'll
> post it.

'post it'

> (2) Introduce a simplified version of the c_shadow headers, call them the
> c_legacy headers.  These headers would hoist the existing headers
> into the _C_legacy namespace (as the c_shadow headers do) and inject
> the relevant bits into the std namespace (as the c_shadow headers do),
> but the wrappers would be much simpler.  Simple works.  The c_shadow
> headers would still be available for someone to adopt as a project,
> and the c_std headers would still be available where needed.

Sounds encouraging. I think simplified is good, too.

I'd suggest taking the existing c_std headers and squestering inside of 
_C_legacy or whatever instead of starting with the existing c_shadow files.
Some of the c_shadow bits are too complex and prone to failure: we don't 
really need to wrap in extern "C", for example (just the namespace will work)

There will be no point in the c_shadow headers if this works, right? If 
we could cut down on complexity it would be a good idea.

> (3) With change (1), the work I did for the Solaris 8 headers can be
> integrated.  I imagine some of the patches to the GCC trunk (fixincl
> and the front end) would have to be rechecked, but the rest could
> just plug in.  I still don't have a Solaris box to play with.

Right. I'd still like to see this stuff go in, but it has to be in a more 
refined (read: working) shape before it can be set loose on the rest of us.

-benjamin