This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Proposed header changes (for the trunk)


On Tue, May 15, 2001 at 09:57:12PM -0400, Stephen M. Webb wrote:
>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.

It's my understanding that the c_shadow headers (once fixed) are/were
where we're supposed to be heading.  The other two methods are only there
for various stages of incompatability, i.e., they're not supposed to
be compliant.


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

This sounds good.  I can't think of any problems.


> (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'm interested in how they are "the same as c_shadow, but simpler."
Simpler /how/?  If you can put up a patch for this, that'd help explain what
you mean; I can think of a few ways in which c_shadow can be simplified,
but they may not be the same ways as what you're thinking.


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

I'd be happy to test any patches for Solaris 8... ah, does Sol8 work on the
mainline now?  It was broken on the trunk but working on the branch last
I tried.  Anyhow.  Unfortunately, I can't give you access to these boxes,
but testing patches shouldn't be a problem.


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

The voices in my head collectively think that posting the patches would
be good.  I don't know what the other maintainers say.  :-)


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]