Proposed header changes (for the trunk)

[Stephen M. Webb]

I'd like to propose a change to the libstdc++ headers in an effort to solve
some of the ongoing problems (and, well, to try to get closure on the Solaris 8
support I was doing a while back).  I wouldn't mind a little feedback before I
spend too much more time on it.

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.

Here's my plan, and it's backed by some tested development efforts.

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

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

I am currently working up a patch for this, I could expedite the work if
there's interest.

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


So, if you've read this far, let me know if it's worth my while to continue
or if you collectively think I should perhaps move down a different path.

 -- 

Stephen M. Webb
Principal Consultant, Bregmasoft
stephen at bregmasoft dot com