This is a slightly non-trivial problem. Right now we have 1.95.2 code which we are branding on win32 from the xml.dsp file as 1.95.1, so that's already a blinking neon sign that we've got problems.
Be assured, this is one of two issues that stimied my release of 0.9.x over the weekend, and one I believe we must fix in the release - at least correctly identify the version (!) and preferably do so through either some magic in buildconf, or upon build on win32. Buildconf would make things simpler, we could also fix xml.dsp to contain the correct /D VERISON=\"expat_n.n.n\" tag (something we can't do once the .dsp is loaded into the build environment. Bill D.J. Heap wrote:
I've been having trouble building neon-0.25.3 on Windows and have narrowed the problem down to expat.h. In the Windows build, expat.h is simply type'd from expat.h.in which, of course, doesn't do anything with the @EXPAT_MAJOR_VERSION@ and causes the preprocessor to croak when neon tries to use the XML_MAJOR_VERSION defines. Presumably, the build needs to be more intelligent about expat.h.in and replace the @EXPAT_..._VERSION@ parameters with real version numbers, right? Or am I doing something incorrectly? Thanks! DJ .
