Both Serf and Subversion default to using the shared library version of apr,
but have a flag to switch to using the static library version.
Subversion uses the expat apis directly, and both serf and subversion hardcode
‘xml.lib’ in their buildscripts. Subversion has a hack to also support
libexpat.lib for some other builds (probably recently added for somebody using
the makefile build). We define ‘XML_STATIC’ in both shared and static library
cases.
Bert
From: William A Rowe Jr [mailto:wr...@rowe-clan.net]
Sent: woensdag 4 oktober 2017 19:21
To: Bert Huijben <b...@qqmail.nl>
Cc: APR Developer List <dev@apr.apache.org>
Subject: RE: [PATCH] Building apr-util with recent libexpat2 using CMake
Question,
Is their default build using libapr-1.lib or apr-1.lib for svn and for serf?
I'm trying to wire in a choice for expat.lib (ambiguous) vs libexpat.lib
(always dynamic) vs libexpatMT.lib (clearly static.)
Expat.lib is ambiguous because of the way their experimental cmake build is
structured. I'll be raising a ticket about this. We want to decipher whether
the XML_STATIC is needed. If I understood right, svn is going to directly
access expat APIs? So it would need similar surety about the cpp flags.
The project policy change in 1.6.0 set this all in motion, unfortunately the
cmakefiles.txt and xml.dsp masked the issue. Like on Unix, this necessitates
some build changes by consuming projects. My goal is to minimize these changes.
On Oct 4, 2017 12:07, "Bert Huijben" <b...@qqmail.nl <mailto:b...@qqmail.nl> >
wrote:
> -----Original Message-----
> From: William A Rowe Jr [mailto:wr...@rowe-clan.net
> <mailto:wr...@rowe-clan.net> ]
> Sent: woensdag 4 oktober 2017 18:14
> To: Bert Huijben <b...@qqmail.nl <mailto:b...@qqmail.nl> >
> Cc: APR Developer List <dev@apr.apache.org <mailto:dev@apr.apache.org> >
> Subject: Re: [PATCH] Building apr-util with recent libexpat2 using CMake
>
> On Wed, Oct 4, 2017 at 10:23 AM, Bert Huijben <b...@qqmail.nl
> <mailto:b...@qqmail.nl> > wrote:
> > Hi,
> >
> > Building apr-util with a recent libexpat2 (2.2.4) requires referencing
> > an additional .c file on Windows. The attached patch fixes the CMake build.
> > Perhaps somebody more experienced with CMake can create a patch that
> > would be compatible with older and newer versions.
> >
> > Note that including this file on other platforms is safe. It will just
> > be an almost empty file on those platforms.
>
> Actually, this goes the other way. CMakeLists.txt should only reference the
> desired libexpat[MT].lib, not source files in expat. It's up to the expat
> maintainers to describe the Windows build, which they've been doing well
> since the late 1.9x flavors.
>
> See the "expat removed" thread. Please check out 1.6.x branch of apr-util for
> the currently proposed solution I intend to tag, once I've resolved all of
> Steffen's issues (some offlist, since his connectivity was limited over the
> weekend.)
Currently the cmake file on trunk directly references these files from the main
apr project, so this code is currently broken in the same way.
Currently both Apache Subversion and Apache Serf rely on finding the xml
library produced by the apr-util (or apr 2.0) build in their build scripts for
Windows on all maintenance branches... without code in these scripts to
override this.
Bert
