Extensionless headers

[Nathan Myers]

On Tue, Jan 08, 2002 at 11:11:30AM -0800, Benjamin Kosnik wrote:
> I'm most interested in seeing what problems show up, and fixing them if 
> and when they exist. 

That's the classic route to mush: discard the known global solution, and 
then hack and patch around all the problems it used to solve, one at a 
time.  Claim extra points for saying problems that are hard or a nuisance 
to work around don't count.  

What you talking about is substituting directory placement for filename 
extensions.  Then you have to maintain a complete list of the directories 
where headers can go.  Only headers may go in them -- except for the 
CVS subdirectory, and other header subdirectories, and other things 
to be determined.  Scripts that operate on sources have to arrange to 
skip the non-headers, somehow.

And all for what?  The other projects and the rest of the Gcc team
will be forced to admire our cleverness and the elegance of our header 
names.  They will all adopt our elegant solution and thank us for our 
cleverness in their respective ACKNOWLEDGEMENTS files.

Let's do this instead.  (This is a lot like Phil's suggestion.)
Eliminate all the files that just sub-include another header, such 
as string -> bits/std_string.h.  Leave bits/std_string.h where it 
is, and leave everything that includes it unchanged.  Generate the 
extensionless names at install time, as symbolic links where possible,
or as one-liner files containing only an #include_next.  

Maintain the policy that libstdc++ files only ever include files like
<bits/*.h>.  Extensions are treated the same as other headers, with or
without extensions, but anything in the library that includes one uses
a ".h" name.

For extra credit, change the subdirectory name from "bits" to something 
else users are less likely to want to use, and that is less likely to 
collide with glibc's names, such as "_std" or "std.std".  (The "bits" 
name was copied from glibc, probably unwisely.)

Nathan Myers
ncm at cantrip dot org