FreeLists / openbeosnetteam / [openbeosnetteam] Re: Networking and the new Build System

[Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>]

On 2005-10-27 at 18:31:48 [+0200], Philippe Houdoin wrote:
> 
> > 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?

Yep.

> 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?

Yep. You can, of course, explicitely add the headers via UsePublicHeaders, if 
not compiling for Haiku. In case of the BNet* classes, this is even 
relatively harmless, since they live in a separate directory and using them 
won't get you more than you want (as in the case of the POSIX headers).

> What about our own private methods definition 
> then?

If they are in private headers, you have to add those header directories 
explicitly anyway. This will also work when not compiling for Haiku.

> We're supposed to be source compatible, no?

Mostly, yes.

> So our own trunk/headers/* 
> public
> headers are supposed to be compatible. Otherwise they should be fixed. Or 
> did I
> miss something here?

As you should best know, we are not 100% source compatible -- the networking 
stuff is an excellent example. But that's not even the point. BeOS simply 
isn't forward binary compatible with Haiku. Hence when compiling something 
with our headers, there's a chance that it won't work under BeOS.

> > 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/*

Maybe putting them into a separate header tree isn't that bad an idea. At 
least it would solve the problem, that you can't use the networking headers 
without also getting all the other POSIX headers.

> > 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!
> :-)

Well, you have to live with the result, when incompatibilities cause weird 
hard-reproducible problems. :-)

> > 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 :-)

OK, then I'll see, how far I get first. I would be delighted to hear, what to 
do about the usage of the atomic_add64() function, that doesn't exists under 
BeOS R5 (unless I'm not mistaken).

CU, Ingo