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. 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). > - 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? 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? The problems you're highlighting about static builds are the downsides of combining apr and apr-util. Regards, Graham --
