Considering that it hasn't been much activity around the internal libraries for long time, I was wondering if it still makes sense to keep them like they are or merge them in the core.

Recently, during the devel meeting, I relocated a couple of them to the archive. The lib/binrpc (and print) can have the same fate, being not actually used.

The srdb1 is very common and I guess it is very rare the case when a deployment is used without a module not depending on it (e.g., even if dispatcher is used with a list file, the code is still linked to this library).
The trie library is small and ims is actually a set of getter functions for message attribtues/headers.

The srdb2 is not used much, but I think the right approach for it is to change the modules using it to libsrdb1 and get rid of it completely sometime in the future. Till then the code is not big and can reside as part of the core.

The benefits I see are in simplifying the build system (current makefiles and hopefully soon-to-be-merged the one based on cmake), reducing also the time to compute compile and link dependencies; getting rid of packaging complexity (same library may be needed by different modules, which, when packaged separately, the library has to be in a 3rd package, or have dependency of the other module's package -- probably now the libs are shipped with the core package).

The code for libs can stay at the same location, so source code for modules doesn't need to be updated, just that they are compiled with the core, removing internal libs from makefiles.

Thinking that we go for 6.0.x, clarifying the plans for this component and cleaning it, if decided so, should fit well in such version number jump.

Opinions?

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.