On 12/9/21 9:18 PM, Greg Stein wrote:
> On Thu, Dec 9, 2021 at 1:55 PM Ruediger Pluem <rpl...@apache.org
> <mailto:rpl...@apache.org>> wrote:
>
> 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> <mailto: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
>
>
> I think dropping Netware in 1.8 would be prohibited by our versioning
> guidelines. Elimination of a feature is pretty big.
>
> That said: I'm +0 on removing it. I doubt anybody would actually complain.
>
> The rest of email is simply how it could be done for 1.8 while keeping the
> same API/ABI, to meet the versioning rules.
>
>
> 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
>
>
> That might work? For some reason, my spidey-sense is saying there are
> pitfalls in simply renaming a symbol in the preprocessor.
> Certainly, for sure the debug and stack traces would be wonky. There wouldn't
> be any true ABI entrypoint named apr_foo() etc.
> (think: dynamic lookup)
Using wrappers and thus creating the symbols would be fine for me as well and
for the reasons you mention is probably the better
approach.
Regards
Rüdiger
