Re: RFC: APR 2.0 modularization

On 22 Apr 2024, at 12:52, Ivan Zhakov <[email protected]> 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
--