[openbeos] Re: BIG change in progress
- From: "Marcus Overhagen" <ml@xxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 29 Aug 2002 00:39:30 CEST (+0200)
> > - I'm making the build independed of the header files from
> > /boot/develop/headers
> > - I'm making the kernel build use BeOS headers where applicable.
> > - I'm adding header files for the kits when they are required for the build.
>
> OK, but why? As header files become available in our tree, they won't
> be pulled in from /boot/develop/headers anyway, so I don't understand
> the need for this.
Currently, we have headers for the kernel, and headers for other libraries.
The problem is that both should be places in the public header directory.
One example is sys/types.h, that currently includes the private ktypes.h
This is fine for the kernel, but not BeOS compatible replacement, so you
can't compile anything of the libraries that includes this file.
For example compiling the new network libraries requires new headers
from the public posix directory, which also will include the kernel headers
Of couse, you can always tweak the Jmafiles to get this working anyway,
but I don't think this is a good solution as it gets more complicated.
> > - I'm merging ktypes.h sys/types.h OS.h SupportDefs.h
>
> Why? Will those headers still be available and simply refer to the new
> "master" header?
They will still be available. But currently, they do duplicate defines,
and give compile errors/warnings. sys/types.h is included by
every SupportDefs.h anyway, and I'm just moving some typdefs
to resolve collisions. They will stay also compatible with BeOS.
> > - This means, I'm probably going to change "int" into "status_t" or into
> > "int32" where required.
>
> Is there a technical reason for doing this?
Yes. But this is just one of the examples
On BeOS, "long" == "int32" == "status_t"
On NewOS, "int" == "int32" == "status_t"
Both are 32 bit wide. But, many functions return int in the kernel.
But this gives compiler warnings and errors when using prototypes
from the BeOS headers. As we won't change the headers, this will
have to be done in the implementations.
> My big question is "why the heck are you doing this?" ;P What problem
> does this solve or goal does it achieve? I'm not trying to be
> antagonistic, I just want to understand your motivation -- if for no
> other reason than to help me avoid making a necessary task more
> difficult for you. =)
The main motivation is to get a smoth integration of networking, kernel, and
BeOS
headers. At the same time, this makes the kernel more BeOS like, and also gets
us a cleaner build system, with less unexpected dependencies.
It also gets us more functionality when we can add libc/libroot functions.
This should also create the possibility to compile the whole tree on
Windows or Linux.
regards
Marcus
Other related posts:
