RE: [PATCH] Building apr-util with recent libexpat2 using CMake

[William A Rowe Jr]

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"  wrote:

>
>
> > -Original Message-
> > From: William A Rowe Jr [mailto:wr...@rowe-clan.net]
> > Sent: woensdag 4 oktober 2017 18:14
> > To: Bert Huijben 
> > Cc: APR Developer List 
> > Subject: Re: [PATCH] Building apr-util with recent libexpat2 using CMake
> >
> > On Wed, Oct 4, 2017 at 10:23 AM, Bert Huijben  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
>
>

RE: [PATCH] Building apr-util with recent libexpat2 using CMake

[Bert Huijben]

> -Original Message-
> From: William A Rowe Jr [mailto:wr...@rowe-clan.net]
> Sent: woensdag 4 oktober 2017 18:14
> To: Bert Huijben 
> Cc: APR Developer List 
> Subject: Re: [PATCH] Building apr-util with recent libexpat2 using CMake
> 
> On Wed, Oct 4, 2017 at 10:23 AM, Bert Huijben  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

Re: [PATCH] Building apr-util with recent libexpat2 using CMake

[William A Rowe Jr]

On Wed, Oct 4, 2017 at 10:23 AM, Bert Huijben  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.)

[PATCH] Building apr-util with recent libexpat2 using CMake

[Bert Huijben]

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.

Bert

--
Inline version:


Index: CMakeLists.txt
===
--- CMakeLists.txt  (revision 1811061)
+++ CMakeLists.txt  (working copy)
@@ -221,6 +221,7 @@
   xml/expat/lib/xmlrole.c
   xml/expat/lib/xmltok.c
   xml/expat/lib/xmlparse.c
+  xml/expat/lib/loadlibrary.c
 )
 
 SET(install_targets)


201710-recent-expat.patch
Description: Binary data