From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902944
Hi!
We've got several local kamailio modules, and it would be nice to be able to build them separately and not have to hook them into the kamailio source and build systems. I suppose others might find this useful too.
I started pondering what adding support for this would imply, and I think the first step is whether this is something you think upstream and you'd be happy supporting? It could be that the internal interfaces are completely unstable and providing this might be a support nightmare, for example, or other similar concerns.
I think what would be needed is:
- Support installing the library .so symlinks into the -dev package. (The module .so I think would need to stay in the main and module packages, because some stuff loads them as module.so directly?)
- Support installing the kamailio core, library and module .h files into the -dev package. AFAIUI modules can have inter-module dependencies and they might use interfaces from both kamailio core itself, the shared libraries or other modules.
- Provide a pkg-config file with the necessary compile and link runes (-I, -L, -rpath and similar) to be able to build 3rd party modules easily.
While checking this, I noticed there's a src/lib/Makefile.defs, which has a TYPE variable to install headers and similar, but it does not appear to be currently used?
Thanks, Guillem
This is an interesting request, it needs to be discussed from different sides:
- are our internal core interfaces stable enough - do we actually want to expose them officially against 3rd party modules - regarding the licensing, the core is BSD licensed, this would be fine, but if you start to load/compaile against GPL modules the situation gets complicate - support and effort for implementation vs. usage
If the original reporter from Debian want to proceed here, I would suggest to start a discussion about it on our the sr-dev list.
On a different angle - are there modules not in our distribution? Any reason not to include them in Kamailio? It's not like the asterisk situation where people may have opinions about Sangoma/Digium licensing schemes and want to stay outside. We have historically been very open to include modules. For me this is not really an issue and if it is, we need to discuss the reasons why someone would like to create a Kamailio module and have a separate official Debian package for it. I could have missed something, but I don't remember any such situation.
Well, that is what Sipwise is doing for a long time. You can see their modules here: https://github.com/sipwise/kamailio/tree/master/debian/patches/sipwise
Maybe @guillemj or @agranig would like to comment on this request here.
Bigger companies have also internal modules, that might be proprietary or too special to be included in the open source repository. The approach chosen by sipgate and others to just add this with the Debian patch system works ok, at least in my experience.
Over all I do not have anything against, but it might be a more complex process that some could expect.
A good step was already done with source code restructuring done for v5.0, now all header files are inside src/ folder, so that can be the base dir when compiling from sources and can be what would result after installation in something like /usr/include/kamailio/, then inside it place the core, lib, modules headers. The most of the work would be with shared objects, to expose them properly for kamailio usage as well as compiler linking.
If anyone wants to do the work, I would say to go ahead and then make the pull request. If doesn't break the current use, I see no reason not to merge.
I am even willing to propose to get rid of internal libraries if that would simplify things. I had it in mind to start a discussion about it even before this was proposed, so just as a hint here, I will make a dedicated topic for it.
This issue is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.
Closed #1752 as not planned.
-
Daniel-Constantin Mierla -
github-actions[bot]
-
Henning Westerholt
-
Olle E. Johansson
-
Victor Seva