
|
[openbeosnetteam]
||
[Date Prev]
[10-2005 Date Index]
[Date Next]
||
[Thread Prev]
[10-2005 Thread Index]
[Thread Next]
[openbeosnetteam] Re: Networking and the new Build System
- From: Philippe Houdoin <philippe.houdoin@xxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Thu, 27 Oct 2005 18:31:48 +0200
Hi Ingo,
> If the TARGET_PLATFORM is anything else, the build system builds for the
> host platform, which has to be at least compatible with what is set as
> target platform (i.e. you can build for R5 under Dan0, but not the other
> way around). Therefore it uses the tools, headers, and libraries of the
> host platform.
*Only* host platform headers (/boot/develop/headers/*) are used in such cases?
You mean for example that when compiling for R5 the
trunk/src/kits/network/libnetapi/NetEndpoint.cpp the NetEndpoint.h header found
will be the R5 one, not our? What about our own private methods definition then?
We're supposed to be source compatible, no? So our own trunk/headers/* public
headers are supposed to be compatible. Otherwise they should be fixed. Or did I
miss something here?
> The real problem is that public networking headers are used that don't
> exist on BeOS R5 (and one probably wouldn't want to use them anyway).
Agreed. That was and still is an issue we encountered since start.
Many internal networking stuffs are actually defined by POSIX files. Some should
be private and we tried to sort them out and moved them under
headers/private/net.
Maybe it's time to check if we didn't miss some ones.
> if $(TARGET_PLATFORM) != haiku {
> UseHeaders [ FDirName $(HAIKU_TOP) headers posix ] : true ;
> }
>
> I.e. when not compiling for Haiku we use Haiku's public POSIX headers.
Yep, that's what I worried about too. Due to its UNIXish taint, everything are
expected to be defined in (public) POSIX headers.
Except that under R5 and BONE these headers don't exists at all or are not
source compatible, thank for net_server/BONE broken compatibility.
I really dunno how we could fix it so it works fine for all three source
uncompatible network environment. Well, two, as our public headers should be
source compatible with BONE/Dano/Zeta ones, just located under POSIX instead of
headers/be/bone/*
> But besides that using POSIX headers indeed mean using *all* POSIX headers,
> not only the networking headers. This is not correct, though it may work as
> long as Haiku is basically source and binary compatible with BeOS.
Argh. That way at least we turn building the network kit under non-haiku target
platforms into a new source and binary compatibility check!
:-)
> How shall we proceed? Shall I try and fix things before merging the build
> system changes into the trunk or do you want to do that yourself afterwards?
Well, the short fix seems to be the one you tried/are suggesting: add explicit
haiku headers usage where it needs. If you can't do it before merging the build
system, we'll try to do it afterward, with your help :-)
- Philippe
|

|