On Thu, Dec 9, 2021 at 1:55 PM Ruediger Pluem <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>> 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) > 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. > Right. Note: I'm not really fussed about any approach (since I'm not the one doing that work). I wrote the versioning guidelines 20 years ago. Just trying to describe an approach that would create the new apr_foo() entrypoints and symbols, yet maintain the API/ABI restrictions. Cheers, -g
