apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: 1.6 apr/apr-util scope/timetable?
Date Sat, 17 Dec 2016 07:54:00 GMT
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.

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.

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?


> 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?

Mime
View raw message