On 3 December 2016 at 18:40, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Sat, Dec 3, 2016 at 6:00 AM, Ivan Zhakov <i...@visualsvn.com> wrote: >> 1. Currently apr 1.6.x doesn't build on Windows using makefiles: >> [[[ >> link.exe @C:\Users\ivan\AppData\Local\Temp\nm2BCE.tmp >> Creating library .\x64\Release\libapr-1.lib and object >> .\x64\Release\libapr-1.exp >> poll.obj : error LNK2019: unresolved external symbol >> apr_poll_drain_wakeup_pipe referenced in function impl_pollset_poll >> select.obj : error LNK2001: unresolved external symbol >> apr_poll_drain_wakeup_pipe >> pollcb.obj : error LNK2019: unresolved external symbol >> apr_poll_create_wakeup_pipe referenced in function >> apr_pollcb_create_ex >> pollset.obj : error LNK2001: unresolved external symbol >> apr_poll_create_wakeup_pipe >> pollcb.obj : error LNK2019: unresolved external symbol >> apr_poll_close_wakeup_pipe referenced in function pollcb_cleanup >> pollset.obj : error LNK2001: unresolved external symbol >> apr_poll_close_wakeup_pipe >> .\x64\Release\libapr-1.dll : fatal error LNK1120: 3 unresolved externals >> NMAKE : fatal error U1077: '"C:\Program Files >> (x86)\VS14\VC\BIN\amd64\link.exe"' : return code '0x460' >> Stop. >> NMAKE : fatal error U1077: '"C:\Program Files >> (x86)\VS14\VC\BIN\amd64\nmake.exe"' : return code '0x2' >> Stop. >> ]]] >> >> Attached patch apr-1.6.x-win32-fix-makefiles-v1.patch.txt fixes this >> problem. There is no makefiles for Windows on trunk, so how should I >> proceed? May I just commit this patch to 1.6.x branch or it's better >> to propose it to STATUS? > > > +1 to simply commit. "windows makefiles" (as derived from .dsp/.dsw) > had proven too volatile to leave on trunk, a lot like "configure" itself. > The theory had been that 1.released doesn't change all that much > again, even as trunk is expanded and refactored. > Committed in r1772477.
>> 2. The same problem with CMake build. There is no such problem on >> trunk. Attached patch apr-1.6.x-win32-fix-cmake-v1.patch >> Committed in r1772478. >> 3. Compilation fails due unresolved external symbol >> file_socket_pipe_close referenced in function >> _apr_poll_close_wakeup_pipe. This happens because there is no >> file_socket_pipe_close() function on the 1.6.x branch: it's named >> apr_file_socket_pipe_close(). Solution could either backport r892386 >> [1] from trunk or apply attached patch >> (apr-1.6.x-unix-wakeup.patch.txt) . The r892386 doesn't merge cleanly >> so I think applying local patch to branch is better. >> >> I'm not familiar with APR release/backport process yet, so please >> excuse me if my questions are stupid. >> >> [1] https://svn.apache.org/r892386 > > > Nope, no dumb questions here. > > I'm wondering, where do we go on trunk with 2.0 on Windows, > now that we can emit solution/project files from CMake, or just > straightforward .mak files? It insisting on a local install of CMake > all that much of a hassle for the Windows build machine? > >From the library consumer perspective it's always better when library can be build using native tools. For Windows it's .mak files or msbuild scripts. Requiring tools like CMake is not only adds additional dependency to install. It also it's another tools with it's own quirks/problems etc. As anecdotal evidence I still cannot build APR 2.0 using CMake, because I cannot build Expat using CMake. But as library developer things are a little bit more complicated: Visual Studio solution/project files are almost required for good development/debugging experience. In theory CMake generates them, but in practice there are several problems: - CMake pollutes working copy with some unrelated files. - Generated solution/project files are not perfect and to tweak them developer have to deal with CMake. Because of problems above I use my own solution/project files for Apache Serf development and don't use SCons which 'official' build system for Serf. I think ideal build system for library like APR should be: - Hand crafted NMake files to build library from source distribution. - Solution/project files for some predefined version of Visual Studio (currently newer version of Visual Studio supports reading and building solutions/projects created by older Visual Studio version). -- Ivan Zhakov
