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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
>
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,
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
> 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
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
> 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
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" <rle...@codelibre.net> wrote:
>> That said, I'd not be averse to including support for stand
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 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
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
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
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
> 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.
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
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.
>
40 matches
Mail list logo