Extensionless headers

[Nathan Myers]

On Tue, Jan 08, 2002 at 07:18:32PM -0500, Phil Edwards wrote:
> This is a red herring.  We already maintain such a list; it's in the
> compiler.  We manipulate it with -I options.

But where can all the scripts we use get this list?
 
> > Scripts that operate on sources have to arrange to 
> > skip the non-headers, somehow.
> 
> I've already given the find command for this (although I forgot to prune
> the CVS subdirs; note that this won't be a problem for users).  Yes,
> it's annoying for us developers, and I would like to see this changed,
> but it's not a world-shattering problem.

We're all developers here.  Users who don't look at the libstc++ source
tree have less need to run scripts over it.  Still, I often do find/grep
in /usr/include for symbols of interest.  It is very common, and no 
amount of documentation can eliminate the need for it.  Telling users
they cannot do their searches the normal way is rude.

> I'd like to hear what you find wrong with my suggestion.  We got into
> this because we wanted to simplify the header file scheme, which IMHO is
> a good idea.  

We have std/ on the -I path, so anything you put in there is exposed
as-is (i.e., <std_string.h> as opposed to <bits/std_string.h>).  Users
are allowed to have their own (e.g.) "std_string.h", which would shadow 
ours.

I would like to move further away from naming that is reserved to users; 
it bothers me that we have "bits" and "ext", which user programs being
ported might already have used for their own purposes.

> Your proposal sounds like it's reintroducing that complexity
> on a per-header basis.  Mine keeps things simple across the board.

I think maybe you misread it, as I initially misread yours.  Some 
subdirectory (or other prefix) structure is essential, though, as a 
way to minimize our name footprint.

Nathan Myers
ncm at cantrip dot org