Re: svn commit: r1860745 - /apr/apr/trunk/file_io/win32/dir.c

2019-06-11 Thread William A Rowe Jr
On Tue, Jun 11, 2019 at 1:44 PM Branko Čibej wrote: > We either reserve about 2x buffers for file name transliteration in heap > per thread, or we use the thread stack. As long as we trust that our utf-8 > to ucs-2 logic is rock solid and the allocations and limits are correctly > coded, this

Re: svn commit: r1860745 - /apr/apr/trunk/file_io/win32/dir.c

2019-06-11 Thread Ivan Zhakov
On Tue, 11 Jun 2019 at 17:14, William A Rowe Jr wrote: > > On Tue, Jun 11, 2019 at 4:15 AM Branko Čibej wrote: >> >> On 07.06.2019 21:58, William A Rowe Jr wrote: >> > I think the optimal way is to allocate a pair of apr thread-specific >> > wchar buffers in each thread's pool on startup, and

Re: buildbot failure in on apr-x64-macosx-trunk

2019-06-11 Thread Branko Čibej
On 11.06.2019 18:36, build...@apache.org wrote: > The Buildbot has detected a new failure on builder apr-x64-macosx-trunk while > building . Full details are available at: > https://ci.apache.org/builders/apr-x64-macosx-trunk/builds/275 > > Buildbot URL: https://ci.apache.org/ > > Buildslave

buildbot failure in on apr-x64-macosx-trunk

2019-06-11 Thread buildbot
The Buildbot has detected a new failure on builder apr-x64-macosx-trunk while building . Full details are available at: https://ci.apache.org/builders/apr-x64-macosx-trunk/builds/275 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: svn-x64-macosx-dgvrs Build Reason: The

Re: svn commit: r1860980 - /apr/apr/trunk/build/crypto.m4

2019-06-11 Thread William A Rowe Jr
I'm totally confused, these libs have been installed across three paths? If not, isn't that an autoconf task to link to the one and only one preferred target on rebuilds, in spite of later package adds? On Mon, Jun 10, 2019 at 3:47 PM wrote: > Author: minfrin > Date: Mon Jun 10 20:47:36 2019

Re: svn commit: r1860745 - /apr/apr/trunk/file_io/win32/dir.c

2019-06-11 Thread William A Rowe Jr
On Tue, Jun 11, 2019 at 9:14 AM William A Rowe Jr wrote: > On Tue, Jun 11, 2019 at 4:15 AM Branko Čibej wrote: > >> On 07.06.2019 21:58, William A Rowe Jr wrote: >> > I think the optimal way is to allocate a pair of apr thread-specific >> > wchar buffers in each thread's pool on startup, and

Re: svn commit: r1860745 - /apr/apr/trunk/file_io/win32/dir.c

2019-06-11 Thread William A Rowe Jr
On Tue, Jun 11, 2019 at 4:15 AM Branko Čibej wrote: > On 07.06.2019 21:58, William A Rowe Jr wrote: > > I think the optimal way is to allocate a pair of apr thread-specific > > wchar buffers in each thread's pool on startup, and use those > > exclusively per-thread for wchar translations. We

Re: svn commit: r1860745 - /apr/apr/trunk/file_io/win32/dir.c

2019-06-11 Thread Branko Čibej
On 07.06.2019 21:58, William A Rowe Jr wrote: > I think the optimal way is to allocate a pair of apr thread-specific > wchar buffers in each thread's pool on startup, and use those > exclusively per-thread for wchar translations. We could be looking at > 64k/thread exclusively for name

Re: Building apr using VS2017

2019-06-11 Thread Michal Karm
On 06/11/2019 09:25 AM, Ge, Teng wrote: > > Hi, > > I’m wondering if it’s possible to build the apr using VS2017? Or has any one > done it? > > I was trying to build it with DSW/nmake/cmake, but none of them succeeded. > >   > > Thanks, > > Teng > >   > Hi, Yes, it is, apr-1.6.5-901ece0-64.zip

Building apr using VS2017

2019-06-11 Thread Ge, Teng
Hi, I’m wondering if it’s possible to build the apr using VS2017? Or has any one done it? I was trying to build it with DSW/nmake/cmake, but none of them succeeded. Thanks, Teng