Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote: > > FWIW, libopenbeos.so links against libbe.so as well - we would need > > to > > change that as well... > Ah, I didn't even think this one is still there. I haven't tested it > yet, > but if our kits are complete enough, we should be able to just remove > it. > libbe code that needs to be accessed for any reason should be made > available through libbeadapter. Indeed, I guess one should have the unit test run (compiling them should be enough, though) in this case to find out about any problems? > > AFAIK only the BApplication and ViewInterface stuff relies on the > > test > > platform. Any other things? > > How hard would it be to put them into an add-on? > Not that hard, I hope. What has to be taken care of is that objects > may > cross implementations by passing them through the interface. E.g. a > BRegion > passed to the add-on may have been created with the libopenbeos code > and > will be used by the libbe code. That's exactly what I was thinking about. I don't have a good idea for that, though. It would certainly help to find out if we pass any of these regions to a libbe.so API. > > For a start, a shared library could help as well, BTW, and would be > > much simpler to do, although it wouldn't guarantee us that we're > > free > > of host dependencies. > Why not? There should be little difference between a library and an > add-on, > save that a library will be easier to use. Or do I miss something? Yes, I think you're right, they should be equivalent. I thought that if the app_server links against lib X that links against libbe.so, that one would already bind the symbols needed from libbe.so, but IIRC this is not the case. Bye, Axel.