On 17 December 2016 at 10:54, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Sat, Dec 17, 2016 at 1:34 AM, Ivan Zhakov <i...@visualsvn.com> wrote: >> >> 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. > > > Ok, in all fairness, that's not a fair comment, not one VS toolchain > works like the prior revision of the VS toolchain, unlike most all > *nix toolchains. > I've different experience: I'm switching from toolchain VS 2010 to VS2012, VS2013, VS2015 and VS2017 without problems.
> And the size of the CMake toolchain is essentially nothing, compared > to the scope of any MSVC + SDK toolchain. Yes, it is an extra tool, > and so are bash/sed/awk/libtool/etc/etc on *nix. The problem with generators like CMake that they multiply problems in MSVC + SDK. > > Digging into expat 2.2.0 because that's all we have to discuss... > it is CMake. And that is the only current version. Your objection, > once again? > I personally still prefer using native build tools, like APR *already* uses for other platforms: autoconf/configure for *nix, NWGNUMake for Netware. The only benefit would be if CMake will be possible for *all* platforms, for *nix feel CMake pain too :) In this case benefit would to have single place for included source files etc. >> >> 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. > > > And abspaths that are moronic, but that is sadly by-design. > >> >> - Generated solution/project files are not perfect and to tweak them >> developer have to deal with CMake. > > > Which is different than what arbitrary project/solution files that any > individual projects create? httpd requires at least 12-14 distinct > component builds. > >> >> 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. > > > And I've reinvented all those wheels too, for at least 15 years. > It would be nice to start finding some common reference points. > >> >> 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) > > > All of this has been done. The worst of the best by the OpenSSL > team. The most convoluted by our effort. In the end, fixing the > results of the CMake output might be the straightest line to one > solid solution, and patching CMake in minor respects, especially > if accepted upstream, would be even more efficient. > > Consider that all of your Visual Studio interactive arguments do > apply equally to giving an Eclipse-based gcc developer the same > introspection of the sources, and debugging capabilities. > > Immediate term, based on yet another failed httpd release, is > that .dsp files must die now (or, at least in 2.0 release.) Some > facility for a straightforward makefile should remain, but no one > can argue that an unavailable Microsoft-discarded-by-Sun- > lawsuit product fills that void. > > apr/build/fixwin32mak.pl has existed forever because of how > bogus all of these files are. Why not tweak them to address > our frustration with CMake? > Of course .dsp files must die. I suggest to replace them with straightforward, handwritten makefiles as an official way to build APR on Windows. -- Ivan Zhakov
