[openbeosnetteam] Re: Moving stuff: half done.

> > > I will have a look at them in the later afternoon/evening.
> > 
> > I added Jamfiles to include the libnet(api) libraries, but this 
> > showed many problems
> > with include files that I can't fix. Especially types.h and ktypes.h
> > 
> > I think we could include os/support/SupportDefs.h (needed for int32, 
> > etc.)
> > which includes posix/sys/types.h
> 
> <SupportDefs.h> is included -- directly or indirectly, don't know.

Ok, well. Lets see how this is handled on R5.
On R5, all posix header files include as the very first thing 
the file be_setup.h (or they include another posix file which includes this one)
be_setup.h then includes BeBuild.h

This does *not* give your application the types from SupportDefs, like int32 or 
int64.
I verified this with a program that only includes <stdio.h>, it will fail to 
compile
if int32 is used. Thats how it works for files in the posix header directory.

The files in the be directory all include <SupportDefs.h> when they require 
types
like int32. SupportDefs.h includes <BeBuild.h> at first.

SupportsDefs.h does include <sys/types.h>

My first idea was to move definitions from Support.Defs into sys/types.h, but 
this would be a bad idea. Instead, a much better idea is to include 
SupportDefs.h
at the places where we use sys/types.h

If possible, I'm going to replace the current sys/types.h with the BeOS R5 
sys/types.h
This will break much, but I think this needs to be done and I'm going to fix it 
then.

However I have still a bad feeling about our header problems. We really should
work on getting a compilation that is independent from headers in 
/boot/develop/headers

Marcus





> Obviously <sys/types.h> has to be fixed. It includes <ktypes.h>, which 

> is private header and must not be included from a public one. I tried 
> to add the private kernel headers, but these rely on architecture 
> specific headers and, if those are added too, we get conflicting type 
> definitions for <SupportDefs.h> and <ktypes.h>.
> 
> > What do we do with private/kernel/ktypes.h and the arch/ktypes.h
> 
> ???
> Leave them alone?
> 
> > This needs to be cleaned up a little bit :)
> 
> Definitely.
> 
> BTW, I tried to write a Jamfile for the userland server, but it suffers 
> from the same problem. Sorry guys, until the header issues are solved, 
> I can't be of much help.
Ups, and there goes my hope that you would fix this problem for us,

Other related posts: