apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Zhakov <i...@visualsvn.com>
Subject Re: 1.6 apr/apr-util scope/timetable?
Date Wed, 21 Dec 2016 06:48:44 GMT
On 17 December 2016 at 10:54, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
> On Sat, Dec 17, 2016 at 1:34 AM, Ivan Zhakov <ivan@visualsvn.com> wrote:
>>
>> On 3 December 2016 at 18:40, William A Rowe Jr <wrowe@rowe-clan.net>
>> wrote:
>> > On Sat, Dec 3, 2016 at 6:00 AM, Ivan Zhakov <ivan@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

Mime
View raw message