[openbeos] Re: getting serious about headers
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sun, 10 Aug 2003 11:49:20 +0200 CEST
"Andrew Bachmann" <shatty@xxxxxxxxxxxxx> wrote:
> issue #1. posix unfriendly headers:
Could you give examples, which headers are unfriendly?
I am working on the stdio.h issue, but anything else can be compatible
right now.
> issue #2. headers from gcc:
We already have agreed on using gcc headers where appropriate, since
GCC is our main compiler, and we may want to switch between different
versions (or even compilers) without big trouble.
Those headers shouldn't be part of our repository as it is now (at
least for some headers), but are part of the GCC header path.
When we have our repository compiling natively under GCC 2.95.3 and 3.4
(or whatever is out then), we could reconsider that issue, but I don't
think it's much of a matter.
In any way, it's not a legal issue to use those headers.
> issue #3: missing headers
Sure, there are a lot of missing headers. When me moved NewOS to our
repository, the header directories got messed up completely - the Posix
headers got mixed up with the kernel private headers.
My usual habit was to let those headers staying in the private kernel
directory as long as they haven't been fixed/reviewed/rewritten for
BeOS/Posix compatibility.
> 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?)
As long as we would only cause the need to include some other headers,
I would be fine with it, but of course, we can certainly not break any
binary compatibility.
> 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)
I would be heavily against this change. Most of our headers are
completely hand-written, and everything in posix/ is checked against
BeOS compatibility (at least anything commited by me). Checking out the
FreeBSD headers would mess up that thing totally. And FreeBSD headers
are neither clean nor BeOS compatible, they build up on a different
system - not ours.
> Thoughts or comments?
We should not aim to support much more of Posix than BeOS did - only
those bits and pieces that made it hard porting applications to BeOS.
That would be definitely R2 material.
My proposal would be a bit simpler:
1. check what headers are missing from our posix/ tree, write that
down.
2. move/fix/rewrite existing Posix headers from private/kernel in there
3. add all other which are not delivered by GCC
Now, our primary source for 3. could be either the Posix spec provided
by the OpenGroup Base Specification (which would be my favourite), BeOS
headers (need to be checked against anyway), and *BSD headers.
Adios...
Axel.
Other related posts:
