On Wed, 13 May 2020 at 22:31, Mladen Turk <mt...@apache.org> wrote: > On 13/05/2020 21:04, Ivan Zhakov wrote: > > On Wed, 13 May 2020 at 11:41, Mladen Turk <mt...@apache.org <mailto: > mt...@apache.org>> wrote: > > > > 1. Remove all those .dsp, .dsw .mak files from APR trunk > > None of them works for years. > > > > Not as I objection, but .mak files work for me. > > > > Not for me. .mak files are not present in apr/trunk > There a bunch of .dsp files, but that's hard to maintain > (and they don't work) > > Ok, it seems I confused it with apr 1.7.x branch.
cmake requires less editing and can generate those IDE files > Having two parallel solutions makes no sense to me. > > Yes, but cmake still has the same problem as .mak files: it still separate build system for Windows. As far I understand CMake is cross-platform and it would be nice to use one build system for all platforms. I don't know how hard it is to implement though. > > > 3. Drop all that APR_HAS_ANSI_FS and APR_HAS_UNICODE_FS > > Code in trunk need at least _WIN32_WINNT=0x0601 API > > > > +1. > > Probably, we can move to 0x603 (Windows 8.1/Windows Server 2012 R2) > since supported for Windows 7/Windows Server 2008 R2 ended in January 2020. > Security patches for three years are only available for additional cost. > > I'd stay with 0x0601, because many users have those boxes. > But if there is a real need for API not present in 0x0601, then fine. > > I wanted to use Windows 8.1 API for directory reading, but it's not that important. Let's stay with Windows 7 then. -- Ivan Zhakov
