| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
Hi Alan and all, regarding the idea of fitting the old builsystem to the new requirements here's what I think should be done. So far the old build system does not offer for the correct compilation when cross-building, e.g. amd64 kernel with i386 userland. A very basic table put together from memory is at http://people.debian.org/~kilian/ports.html which you may find interesting. Especially with the Debian buildds it's imperative that the correct userland architecture can be forcibly set to prevent compilation issues with hppa64, i386 userland under amd64 and s390x to just name the most common ones. Further, the "make&&make install" should run through mostly without further manual adjustments and it'd be nice to have a make test for a runtime verification of the just newly built code. From long pain with alpha builds failing subsequently in the next app/library and causing weird bugreports this would be highly apprechiated. ;) Regarding SONAME, a library should expose itself with a correct versioning (libresiprocate.so.X.Y.Z) to the userland so different versions with different API/ABI can be installed alongside each other. So far I have not found support for this in the "old" build system. Yet I'm all open to be led the way if someone can shed some light how this is supposed to be built (and *PLEASE* do not throw this dreadful resip.spec at me!). The mixing of different versions of lib and headers is not an issue at all when using properly packaged binary deb/rpm format. Of course people can still forcibly break stuff, but they can be proven wrong quite easily once the core structure does offer proper version verification from headers and the installed lib via SONAME respectively SOVER. Remains the idea about userland compile-time identification of installed library environment. Probably you know pkg-config which is a means that will serve the purpose. If you feel like adding your own resipconfig.h or resip-config, there's nothing wrong with it (pwlib does that too), but as was concluded already in this thread, other apps should be able to detect the compiletime options of resiprocate from it correctly once installed through packages. As long as this works reliably, it's not important where these functions come from. -- Best regards, Kilian
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil