Re: RFC: APR 2.0 modularization

On Mon, 22 Apr 2024 at 11:03, Nick Kew <[email protected]> wrote:

>
>
> > On 20 Apr 2024, at 11:38, Ivan Zhakov <[email protected]> wrote:
> >
> > Hi,
> >
> > In APR 2.0 we merged APR-Util **project** to APR. Which is IMHO a good
> thing.
>
> Um, apr-util was a separate library, but not really a separate project.
>
> By project I mean separate source tree, separate version etc.

The separation may have been a little OTT, but merging them runs into
> "ain't broke, don't fix", with likely confusion arising from the change to
> a
> familiar status-quo.  But that's just a view from about 20 years too late.
>
> > I would suggest separating APR in different libraries, while keeping
> them in one project/source tree.
> >
> > Something like that:
> > - apr-2
> > - apr-dbd-2
> > - apr-dbm-2
> > - apr-xlate-2 (?)
> > - apr-crypto-2
> > - apr-xml-2
> > - apr-ldap-2
> > - apr-memcache-2
> > - apr-redis-2
>
> Works in principle, though packagers and users should probably have an
> apr-everything
> option alongside those.

I expect that it will be one package, but with several libraries inside.


> 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)
- Modular DSO can be disabled in compile time for some reason

-- 
Ivan Zhakov