On Thu, 14 May 2020 at 11:48, Steffen <i...@apachelounge.com> wrote: > > > > > Good day, > > On Wednesday 13/05/2020 at 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 > > -1 > > I works from the beginning, and can be used with VC6.0 - VS16. > > It is funny that I get once in a while requests to build on VC6.0. > > ps. > For your info : > > > Oh no, again an dsp/cmake discussion. But you trigger a new one. > We had a lot discussion at the HTTPD list. > > > It is fully supported by MS and no dependency on externals (like cmake > releases). > Easy to maintain. > > Please tell me what is the exact issue with dsw/dsp/mak. > > When I look at the cmake in current HTTP/Apr GA, it is not good > maintained > and after 6 years years not all is build and has limitations. > > > So keep both, it hurts nobody ! And there a guys who maintain it > (easy). > > > > 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 > +0 Never did some on WCE > > > > 3. Drop all that APR_HAS_ANSI_FS and APR_HAS_UNICODE_FS > > Code in trunk need at least _WIN32_WINNT=0x0601 API > -1 be aware that still 600 boxes are used, special in companies.
Do we really need to keep compatibility code for operating systems that are not supported for years just for a few special companies? They still can use APR 1.x anyway. PS: This topic has been discussed a year ago. Thread: "Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimize apr_file_info_get(APR_FINFO_SIZE) on Windows)" [1] [1] https://mail-archives.apache.org/mod_mbox/apr-dev/201905.mbox/%3ccabw-3ydoqhj7iqptuej0donv4jhrlgglytzpfkckvmz+ueg...@mail.gmail.com%3e -- Ivan Zhakov
