On Mon, 22 Apr 2024 at 14:41, Graham Leggett <minf...@sharp.fm> wrote:
> On 22 Apr 2024, at 12:52, Ivan Zhakov <i...@apache.org> wrote: > > The question is, is it worth it for such a marginal change? >> Have you looked in to the practicalities and verified no major stumbling >> blocks, >> bearing in mind that developer effort tends to be thin on the ground? >> >> Take the Apache Subversion for example: it uses only core features from > APR. But linking to apr 2.0 would lead loading OpenSSL, iconv, ldap (!) to > the process. > Modules may help, but it's not complete solution: > - The are unavailable in static builds > - Some features cannot be moved to modules (see xlate/iconv and ldap for > example) > > > I'm not following - in apr-2, LDAP is purely in a module today. > > My bad: I misread the code. Yes, LDAP is in a module. > This is true in apr-util as well. > > Can you confirm why xlate/iconv cannot be moved to a module? (No > expectation for you to do such a move, just want to understand what makes > it impossible). > > I think it can be done in theory, but I see potential problem: API should be changed or some kind of implicit initialization should be implemented. The same situation with xml API. Another benefit of modular approach is that if you link to apr-xlate-2 or to apr-xml-2 you do not need to handle dynamic DSO load failures. - Modular DSO can be disabled in compile time for some reason > > > If you've disabled modular DSO, you've disabled the split of dependent > libraries into separate modules. If this is a problem, re-enable modular > DSO? > There are two things: APR modular DSO support and support for DSO itself. Modular DSO can be disabled while keeping support for dynamic build. APR modular support is configured at compile time and can be disabled by the distribution maintainer. And modular DSO cannot be enabled in static build, because otherwise the module will link another instance of apr-core. > > I see a lot of work being done on cmake, which is great. Is the isolation > of module dependencies in modules working in cmake the same way it does in > autotools? > > Thanks. Unfortunately I don't have enough knowledge about autotools, but as far I understand CMake is similar to autotools. Off-topic: it would be great to use CMake for all platforms to have only one build system. > The problems you're highlighting about static builds are the downsides of > combining apr and apr-util. > > -- Ivan Zhakov
