On Mon, 22 Apr 2024 at 11:03, Nick Kew <n...@apache.org> wrote: > > > > On 20 Apr 2024, at 11:38, Ivan Zhakov <chemo...@gmail.com> 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
