On 12/9/21 6:10 PM, Greg Stein wrote:
> On Wed, Dec 8, 2021 at 7:08 AM Ruediger Pluem <rpl...@apache.org
> <mailto:rpl...@apache.org>> wrote:
>>...
>
> I think our API / ABI rules do not allow this for 1.8, only for 2.0.
> But the question is if we are wiling to break them for a platform that is
> no longer maintained by us and is out of vendor support
> for many years. Hence it likely will not affect our users if we do this
> in 1.8.
>
>
> You could totally add APR_FOO in 1.8 as a new name for APU_FOO. Or more
> precisely: in apr_legacy.h define APU_FOO in terms of APR_FOO.
>
> Similarly, you could rename aprutil_foo() to apr_foo() and then create a
> wrapper aprutil_foo() that just calls apr_foo().
>
> The ABI would remain the same (all old functions are still present), yet more
> symbols (apr_foo) are introduced in 1.8. Check.
> All APU_FOO symbols are present during compilation, and more symbols
> (APR_FOO) are introduced in 1.8. Check.
>
> And clearly, the wrappers and apr_legacy.h would be tossed in 2.0
I am confused now. My reply above was about dropping Netware support for 1.8.
The APR / APU topic was in the
Re: Get rid of APU api in favor of APR for apr/turk
thread.
But on the APR/APU topic: I guess
#define apr_foo aprutil_foo
would be sufficient as users of 1.8 that would use apr_foo in their code, could
not expect to use 2.0 without recompiling against
2.0, while 1.7 users that use aprutil_foo could expect to run against 1.8
without recompiling.
Regards
Rüdiger
