Vitaly Prapirny wrote on 22/06/2017 10:53:
Roger Leigh wrote on 21/06/2017 17:40:
That line (PlatformUtils.cpp:27) is
#if HAVE_CONFIG_H
#include
#endif
so it either can't cope with "#if xxx" (which is used in many
places), or the error is in the generated "config.h". I'm afraid
you'll
Roger Leigh wrote on 21/06/2017 17:40:
That line (PlatformUtils.cpp:27) is
#if HAVE_CONFIG_H
#include
#endif
so it either can't cope with "#if xxx" (which is used in many places),
or the error is in the generated "config.h". I'm afraid you'll need
to identify the cause of the error here
On 21/06/17 14:53, Vitaly Prapirny wrote:
Roger Leigh wrote on 21/06/2017 13:58:
Sorry, too hasty. Please try this revised patch which actually works.
CMake worked without error, but compilation failed just the same way as
in my previous message.
That line (PlatformUtils.cpp:27) is
#if
Roger Leigh wrote on 21/06/2017 13:58:
Sorry, too hasty. Please try this revised patch which actually works.
CMake worked without error, but compilation failed just the same way as
in my previous message.
Good luck!
Vitaly
On 21/06/17 11:17, Roger Leigh wrote:
On 21/06/17 10:46, Vitaly Prapirny wrote:
Roger Leigh wrote on 21/06/2017 12:20:
On 21/06/17 08:48, Vitaly Prapirny wrote:
I've got an error while running cmake with "Borland Makefiles"
generator and Borland C++ Builder 5 compiler. Is BCB5 still supporte
Roger Leigh wrote on 21/06/2017 13:17:
Thanks. This was a problem with the int type check fallbacks. Please
see the attached patch or this github branch:
https://github.com/rleigh-codelibre/xerces-c/tree/cmake-int-fallback
This was a search-replace error when porting m4/xerces_int_types, and
On 21/06/17 10:46, Vitaly Prapirny wrote:
Roger Leigh wrote on 21/06/2017 12:20:
On 21/06/17 08:48, Vitaly Prapirny wrote:
I've got an error while running cmake with "Borland Makefiles"
generator and Borland C++ Builder 5 compiler. Is BCB5 still supported?
It's not a combination I've person
Roger Leigh wrote on 21/06/2017 12:20:
On 21/06/17 08:48, Vitaly Prapirny wrote:
I've got an error while running cmake with "Borland Makefiles"
generator and Borland C++ Builder 5 compiler. Is BCB5 still supported?
It's not a combination I've personally tested, but I can't see any
evidence th
On 21/06/17 08:48, Vitaly Prapirny wrote:
Roger Leigh wrote on 21/06/2017 09:54:
On 21/06/17 02:42, Cantor, Scott wrote:
Are the Xerces_autoconf_config.borland.hpp and
Xerces_autoconf_config.msvc.hpp files "pre-cmake"? IIRC, I think
those are the hardwired versions used in the old builds.
I
Roger Leigh wrote on 21/06/2017 09:54:
On 21/06/17 02:42, Cantor, Scott wrote:
Are the Xerces_autoconf_config.borland.hpp and
Xerces_autoconf_config.msvc.hpp files "pre-cmake"? IIRC, I think
those are the hardwired versions used in the old builds.
I don't want to leave them on trunk if they'r
On 21/06/17 02:42, Cantor, Scott wrote:
Are the Xerces_autoconf_config.borland.hpp and Xerces_autoconf_config.msvc.hpp files
"pre-cmake"? IIRC, I think those are the hardwired versions used in the old
builds.
I don't want to leave them on trunk if they're going to atrophy and I don't
really i
Roger,
Are the Xerces_autoconf_config.borland.hpp and Xerces_autoconf_config.msvc.hpp
files "pre-cmake"? IIRC, I think those are the hardwired versions used in the
old builds.
I don't want to leave them on trunk if they're going to atrophy and I don't
really imagine we'd be doing anything to e
Roger Leigh writes:
> If we every wanted to drop the Autotools to only have one system to
> maintain, this would provide compatibility with a traditional
> configure/make/make install workflow. I'm not suggesting doing this at this
> point in time, just wanted to mention the existence of this so
On 16/05/17 20:02, Cantor, Scott wrote:
I'm not entirely sure about the question you're asking here. By
autoconf-compatible build files, you're talking about the end result of
configure--the generated Makefiles and headers, or the intermediate
autoconf/make scripts like configure/Makefile.in?
On 6/3/17, 6:02 PM, "Roger Leigh" wrote:
> I guess there's now always the option of deleting some or all of the
> stuff under projects/Win32 if you wanted to avoid updating the version
> in them all!
Oh, I intended to remove all that. My project's going to be moving up to VC2017
anyway.
-- S
On 31/05/17 14:23, Cantor, Scott wrote:
Roger, if you want to check the patch into trunk that's fine. I'm holding off
bumping the versions to 3.2 since it will break your current patch and it would
be best if I figure out how to get the version bumped in the new Windows builds
anyway.
I have
Roger, if you want to check the patch into trunk that's fine. I'm holding off
bumping the versions to 3.2 since it will break your current patch and it would
be best if I figure out how to get the version bumped in the new Windows builds
anyway.
-- Scott
On 2017-05-17 17:30, Cantor, Scott wrote:
On 5/17/17, 12:21 PM, "rle...@codelibre.net"
wrote:
I spoke too soon; it's not working for the VS generators on Windows
when
using multiple configurations. I'll fix this up tomorrow.
FWIW, the names currently are the same for 32 and 64 builds. Tha
On 5/17/17, 12:21 PM, "rle...@codelibre.net" wrote:
> I spoke too soon; it's not working for the VS generators on Windows when
> using multiple configurations. I'll fix this up tomorrow.
FWIW, the names currently are the same for 32 and 64 builds. That probably is
as much because of the timin
On 2017-05-17 16:35, rle...@codelibre.net wrote:
On 2017-05-17 16:26, Cantor, Scott wrote:
On 5/17/17, 11:11 AM, "rle...@codelibre.net"
wrote:
I've attached a followup patch, also on my cmake-trunk github branch,
which does this. With this patch applied, you should get identical
versioning
On 2017-05-17 16:26, Cantor, Scott wrote:
On 5/17/17, 11:11 AM, "rle...@codelibre.net"
wrote:
I've attached a followup patch, also on my cmake-trunk github branch,
which does this. With this patch applied, you should get identical
versioning to Autoconf and Visual Studio.
Great, I'm WfH to
On 5/17/17, 11:11 AM, "rle...@codelibre.net" wrote:
> I've attached a followup patch, also on my cmake-trunk github branch,
> which does this. With this patch applied, you should get identical
> versioning to Autoconf and Visual Studio.
Great, I'm WfH today but I'll see what it does on OS X t
On 2017-05-16 21:47, Cantor, Scott wrote:
OK. I'll look into copying the existing Windows and Libtool semantics
exactly. If there's a possibility for aligning them with the next
major
release, we could revisit it then, but I'll revert to the status quo
for
now.
Thx.
I hope that explains
> Definitely not; this is the most complex conversion I've done to date.
> The previous most complex one was libtiff, which also had a fair amount
> of historical stuff. Most are trivial in comparison.
Good to know.
> Hopefully I got the question you were asking. I didn't do this in the
> patch
On 16/05/2017 19:42, Roger Leigh wrote:
configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in
${CMAKE_CURRENT_BINARY_DIR}/src/xercesc/util/Xerces_autoconf_config.hpp
@ONLY)
I should have mentioned: from an autoconf point of view,
"configure_fil
On 16/05/2017 19:02, Cantor, Scott wrote:
There's certainly a good amount of duplication, most of it intentionally
so that the CMake logic mirrors the existing Autoconf feature tests
exactly.
Right, I understand the motivation. And Xerces has one of the more horrendous
config.h messes I've dea
> There's certainly a good amount of duplication, most of it intentionally
> so that the CMake logic mirrors the existing Autoconf feature tests
> exactly.
Right, I understand the motivation. And Xerces has one of the more horrendous
config.h messes I've dealt with, it wouldn't necessarily be so
On 16/05/2017 16:37, Cantor, Scott wrote:
Additionally, if anyone wanted to review and test the patch, it's
attached to the above ticket and also available here:
https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1
Playing with this now, I had two issues I wanted to ask about. One is tha
One issue I did notice on the Windows side is that the DLL names are different
from the existing convention. I would have to personally adjust them back and I
don't think we'd have any reason to want them changed, so I assume that could
be adjusted back?
-- Scott
-
> Secondly, I'm mainly playing with the Windows side of this, and I was unclear
> if it's possible to generate solution files for both 32- and 64-bit at once?
> It
> looks like it picks one to do at a time so that if you had to build both you'd
> have to generate the whole set of files twice in be
> Additionally, if anyone wanted to review and test the patch, it's
> attached to the above ticket and also available here:
> https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1
Playing with this now, I had two issues I wanted to ask about. One is that it
looks like there definitely is a
nt: Wednesday, April 26, 2017 4:04 AM
To: c-dev@xerces.apache.org
Subject: Re: Integrating CMake support for xerces
On 26/04/2017 01:30, Cantor, Scott wrote:
> On 4/25/17, 3:17 PM, "Roger Leigh" wrote:
>> That said, I'd not be averse to including support for standard C++
On 4/26/17, 4:04 AM, "Roger Leigh" wrote:
> Agreed that just moving up to C++98 standard types in and of itself
> would be greatly beneficial. There should be no portability barrier to
> achieving that.
No, definitely not. I've been using the STL and Boost for years now on many
platforms.
>
On 26/04/2017 01:30, Cantor, Scott wrote:
On 4/25/17, 3:17 PM, "Roger Leigh" wrote:
That said, I'd not be averse to including support for standard C++;
using Xerces is often a bugbear due to its age. All our code is now
C++11, with RAII wrappers to make Xerces play nicely. Primarily the
lac
On 4/25/17, 8:30 PM, "Cantor, Scott" wrote:
> So far there is very little divergence, just a few small API additions that
> are unique to the trunk. So I don't foresee anything
> terribly risky about releasing this after some additional fixes, some
> testing, and incorporating your patch.
Othe
On 4/25/17, 3:17 PM, "Roger Leigh" wrote:
> Switching to git would be wonderful. We could also enable CI testing
> with e.g. Travis or some other CI service on github at that time to
> enable testing of all PRs, if that would be accceptable. Or does the
> Apache project provide any equivalen
On 25/04/2017 18:56, Cantor, Scott wrote:
Since we are sharing plans, we (as in Code Synthesis) are planning
to package Xerces-C++ for build2[1] in the near future (but no
definite time-frame). While I haven't looked into this closely
yet, the options we consider range between just packaging it a
> Since we are sharing plans, we (as in Code Synthesis) are planning
> to package Xerces-C++ for build2[1] in the near future (but no
> definite time-frame). While I haven't looked into this closely
> yet, the options we consider range between just packaging it as
> is to pretty much forking it. Th
Hi All,
Cantor, Scott writes:
> So I'm inclined to do the very ugly work of figuring out what's
> missing from the trunk and reviewing all the additional work
> there that was done before the project went into moribundity,
> and try and get a 3.2 out the door this summer.
That would be great.
> I can certainly rebase the cmake-3.1 branch onto trunk if that would
> make sense. However, looking at the differences between the 3.1 branch
> and the trunk, it looks like the trunk might need a fair amount of 3.1
> work applying. Is it a bit out of date?
Yes.
> OK. If there's anything I ca
On 23/04/2017 18:26, Cantor, Scott wrote:
On 4/22/17, 2:59 PM, "Roger Leigh" wrote:
There are two choices for merging it:
- to the 3.1 branch
- to the trunk, for releasing as 3.2
Or a third branch, but I think you already did that via git anyway and that's
simpler in practice so we can dism
On 4/22/17, 2:59 PM, "Roger Leigh" wrote:
> There are two choices for merging it:
> - to the 3.1 branch
> - to the trunk, for releasing as 3.2
Or a third branch, but I think you already did that via git anyway and that's
simpler in practice so we can dismiss that one.
> Since the proposed chan
42 matches
Mail list logo
