On 13.05.2020 11:58, Greg Stein wrote: > Isn't the whole idea of moving to 2.0 to lose the dead weight, and > allow a break in API compatibility?
Sure is. The question is, what's dead weight and what's gratuitous breakage. $ cat apu.h #include "apr.h" #define APU_XXX... ^^^ could be seen as too much, or not. I'm merely pointing out that we can keep some of the source-level compatibility without too much cost. > On Wed, May 13, 2020 at 4:28 AM Branko Čibej <br...@apache.org > <mailto:br...@apache.org>> wrote: > > On 13.05.2020 10:41, Mladen Turk wrote: > > Hi, > > > > Related mostly to Windows port > > > > 1. Remove all those .dsp, .dsw .mak files from APR trunk > > None of them works for years. > > Replace all that with cmake > > 2. Remove all _WIN32_WCE, APR_NOT_IN_WCE > > Just a bunch of code for Windows CE that > > never worked, and no chance it will compile with > > current Windows code > > 3. Drop all that APR_HAS_ANSI_FS and APR_HAS_UNICODE_FS > > Code in trunk need at least _WIN32_WINNT=0x0601 API > > 4. Drop all references to apr-iconv project > > Unusable for years > > 1. Remove all APU_XXX references > > Since the apr-util is apr > > remove all APU_XXX defines and API > > This will cause any coded that's upgrading from apr/apu 1.x to apr 2.x > and uses those symbols to break. That's an unnecessary change of > backwards compatibility. > > > > 2. Netware and OS/2 > > Both platforms are dead for years > > IMHO bunch of relic code no one use > > 3. > https://svn.apache.org/viewvc/apr/apr/trunk/include/apu.h?view=markup > > More then 10 years ago ... > > See above about existing code that uses apr-util 1.x (q.v., > Subversion). > There's no reason to break API compatibility on that level and forcing > all downstream users that want to keep supporting both 1.x and 2.x > from > peppering their code with #if's. > > -- Brane >
