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 

The problems you're highlighting about static builds are the downsides of 
combining apr and apr-util.


Reply via email to