[openbeos] getting serious about headers

Hello all,

As some know I have been trying to build various packages against the OBOS 
headers.  As some 
may suspect we are short a whole bunch of headers, some of our headers are from 
GCC and some 
of our headers aren't posix friendly.  I'd like to explain each of these issues 
in turn, working 
backwards just to be fun.  BTW, this is all my opinion of course. :-)

issue #1. posix unfriendly headers:

Some of our headers are not posix friendly.  This has been brought up before.  
Partially this is 
due to the fact that our headers are sometimes inappropriately dependent on be 
headers.  We 
generally try to minimize the extent to which this is the case.  Other times 
this comes up just 
because we don't know what the right thing is.  I have been working from the 
posix spec 
available online at http://www.opengroup.org/onlinepubs/007904975/ .  
Unfortunately, like many 
specs, it is not very clear on various issues and can be hard to read at times.

issue #2. headers from gcc:

Because we have been short some necessary headers we have been "borrowing" them 
from gcc.  
This may or may not be legal problem.  I certainly don't know about that.  The 
gcc headers are 
large and cluttered however and it would be better for aesthetic and 
comprehensibility purposes 
to replace them with less complex and entangled versions.

issue #3: missing headers

There are a host of headers that are in the posix spec that we don't have in 
our cvs yet.  Some of 
these headers are missing because they never were in beos.  To the extent that 
we don't want to 
extend OBOS support to those headers (which may involve extra implementation 
work not 
fundamental to R1) this isn't a problem.  However, we are also missing a lot of 
headers that were 
in beos and are part of posix too.  For example, although we have a ctype.h, it 
isn't in the public 
headers.  Also, we have no grp.h, regexp.h at all.  There may be others but I 
stopped looking.

My proposal:

The first point I want to make is that I have absolutely no intention of making 
any header 
incompatible with the existing R5 headers.  That is to say, if it compiles with 
the R5 headers, 
then I want it to also compile with OBOS. (if it didn't it sure would defeat 
the purpose, eh?)  I 
don't expect that this will be terribly hard to acheive but if it turns out 
there's some big conflict 
somewhere I will certainly bring it to the list for public comment.

Anyway, that said, here's the proposal: 
1. The current headers subdirectory will be recursively tagged: 
pre_freebsd_merge (or whatever 
you want)
2. The the freebsd headers for the tag RELENG_5_1 (release branch 5.1) will be 
checked out.
3. The posix headers (no freebsd-only headers) will be analyzed next to our 
existing headers and 
merged, or wholesale replaced if possible.
4. The new headers shall be tested by copying the new "headers" directory over 
a clean checkout 
of obos.
5. Step 4 succeeding with no more errors than before, the new headers will be 
committed.
6. The subsequent headers subdirectory will be recursively tagged: 
post_freebsd_merge (or 
whatever you want)

So, who's going to do this? :-)  If the proposal is acceptible, I volunteer.  
I'm on vacation now so I 
have some substantial time to commit to at least this task.  However, I don't 
expect it to take that 
long either. (naive perhaps)

My last point is this: some of the headers that get added as part of this 
process will supply APIs 
that could require substantial work to implement. (posix is big after all)  
Just because we have 
these headers in our cvs shouldn't be construed as a promise to include these 
headers or their 
functionality in R1 or any following version of OBOS.  If you are a developer 
who is ambivalent 
about what to work on you should probably go work on R1 functionality rather 
than implement 
new functionality for new headers.  That said, if your R1 work would like to 
use that 
functionality, or if you prefer to work on that new functionality for whatever 
other reason, 
nobody's stopping you. :-)  This is volunteer work after all. :-)

Thoughts or comments?

Andrew

Other related posts: