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> wrote: > > > > -----Original Message----- > > From: William A Rowe Jr [mailto:wr...@rowe-clan.net] > > Sent: woensdag 4 oktober 2017 18:14 > > 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 > > > > On Wed, Oct 4, 2017 at 10:23 AM, Bert Huijben <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 > >
