On 10/14/11 5:51 AM, "neetha patil" wrote:
>This will require writing of all the data into the file before parsing?
>
>Is there a way to parse the data even before writing into a file (i.e.,
>parsing the data which is in memory)?
Not from a DOM. You can parse from any input stream, including in
On 10/16/11 6:45 AM, "neetha patil" wrote:
>Does Xerces C 2.8 support this method? If so can u please brief it out?
What method?
The API docs are public, and the samples in the project already show
parsing in various contexts.
-- Scott
On 9/1/12 11:51 AM, "Rob Cameron"
wrote:
>
>On thing that is not quite clear to me, though, is the best organization
>for keeping our code in a common framework with existing Xerces
>code.We presently have some source subdirectories for our own
>newly created files, while we have also made edi
On 4/10/13 10:46 AM, "Boris Kolpackov" wrote:
>I was hoping to find time and make a release around June or July.
>It would also be a good idea to spend some time and try to fix some
>new bugs that have been uncovered since the 3.1.0 release. Not sure
>if you would like to wait or if you want to p
On 4/11/13 5:03 AM, "Boris Kolpackov" wrote:
>
>> I would suggest as a way of perhaps reducing time commitment than
>>actually
>> producing binaries for other than Windows is not a great use of time.
>
>Yes, I was also thinking along those lines, especially for platforms
>like HPUX, AIX, etc. But
On 4/11/13 12:35 PM, "shath...@e-z.net" wrote:
>Besides windows builds with VS 2003, 2005, 2008, 2010, 2012 -
>I also perform builds on FreeBSD, PCBSD, and GNU Linux.
>I DO NOT build packages for Debian and RedHat package managers.
>I DO build debug and release builds of Xerces-C from sources.
F
On 4/11/13 12:59 PM, "shath...@e-z.net" wrote:
>
>I can check with Debian and Ubuntu integration teams to see what
>support there is to create (.deb) packages for their distributions.
I can't speak for Ubuntu, but there are official shibboleth packages for
Debian (that I don't maintain) and that
On 11/11/13, 9:20 PM, "Shazni Nazeer" wrote:
>
>I'm new to Apache as well as to xerces. I took an SVN checkout of the
>trunk directory into my Ubuntu as well as to a Windows machine.
You should use the distribution provided on the web site, not a checkout.
> I could successfully build the xerces
Sorry for the noise on this, but this bug just bit me and cost me several days
of debugging despite having been fixed in trunk for close to 3 years now
(XERCESC-1978).
We need a 3.1.2 release very badly. I'm willing to contribute heavily to that
process.
-- Scott
> We need a 3.1.2 release very badly. I'm willing to contribute heavily to that
> process.
Correcting myself, I see that the fix I need was applied to trunk and is part
of, I guess, what would be 3.2, not 3.1.2. I'm not sure if either branch is
active at this point, but if not, I probably have
> Its not very active these days. I don't think we have an official policy on
> Committers from other areas having access. I think it would be great so will
> grant you access if no one objects over the weekend.
I'll stand by. FWIW, I've done very little testing of trunk other than building
it, s
On 2/16/15, 11:52 AM, "Boris Kolpackov" wrote:
>Unless you are prepared to do a good amount of testing (I can help
>somewhat but you will have to take the lead, e.g., package a beta,
>announce it, etc, etc), I would strongly suggest that you do the
>bug-fix release (i.e., 3.1.2). Simply back-port
On 2/16/15, 2:51 PM, "Cantor, Scott" wrote:
>
>The fix on trunk changes the ABI by adding a length field to the string
>pool entries. I probably can come up with one that doesn't by just doing
>the length checking, at the cost of some efficiency.
Correction, it&#x
I've reviewed all the resolved issues against the trunk, and backported
15-20 or so to the branch.
Once I have access I'll commit.
I don't have access to Jira either of course. I "watched" everything I
backported for now, I can at least note it in a comment, but I can't alter
the fix versions
On 2/17/15, 9:01 AM, "Boris Kolpackov" wrote:
>
>What about other platforms?! If this class is defined in a public header
>(i.e., a header that is installed) and the function is virtual, then this
>is an ABI change.
It's a struct, in an impl/ header marked as "do not use", and the struct
itself
On 2/17/15, 9:07 AM, "Boris Kolpackov" wrote:
>
>> I definitely don't have the cycles for a beta and it wouldn't fit my
>> timeline anway.
>
>Then you shouldn't be making the release.
No, I shouldn't, but I didn't see any real alternative either. If somebody
else is going to, I can easily step
On 2/17/15, 9:10 AM, "Boris Kolpackov" wrote:
>
>> I've reviewed all the resolved issues against the trunk, and backported
>> 15-20 or so to the branch.
>>
>> Once I have access I'll commit.
>
>Before you do this have someone review your back-ports to double
>check there are no ABI breakages.
I
On 2/17/15, 3:01 PM, "Boris Kolpackov" wrote:
>
>See it from my POV: I have a ton of users that are pretty happy with
>3.1.1. Now comes Scott and wants to cut a half-tested release just
>to satisfy his immediate needs. Once you do this I will start getting
>emails from my users saying why doesn't
On 2/17/15, 4:00 PM, "Boris Kolpackov" wrote:
>
>> As far as docs go, I obviously need specifics.
>
>You will have to go through the website docs and figure what needs
>updating. If something specific is unclear, ask and I will try to
>help. But don't expect me to provide a step-by-step guide for
On 2/17/15, 4:41 PM, "Cantor, Scott" wrote:
>
>Is this the document mentioned earlier?
>
>http://svn.apache.org/viewvc/xerces/c/admin/release-procedure.txt
>
>If you could at least skim it for any errors, that would be a big help.
Never mind, I missed the note
Irrespective of what the PMC would like me to do with this to get it
formally out there, a beta-1 tarball of the 3.1.2 Xerces-C release is
signed and uploaded to http://people.apache.org/~scantor/
-- Scott
-
To unsubscribe, e-
On 3/2/15, 4:29 PM, "Gareth Reakes" wrote:
>
>> On 2 Mar 2015, at 21:27, Cantor, Scott wrote:
>>
>> Irrespective of what the PMC would like me to do with this to get it
>> formally out there, a beta-1 tarball of the 3.1.2 Xerces-C release is
>> sign
On 3/2/15, 9:39 PM, "Cantor, Scott" wrote:
>Incidentally, I don't know how the ZIPped sources were prepared in the
>past, maybe just manually. But I marked the Windows project files with
>Windows line endings, so it should be possible to directly build for
>Window
A pre-release source distribution of Xerces-C V3.1.2 is available [1],
signed by me, and this is an official call for testers and feedback. The
list of bug fixes in this release can be found in Jira [1], and the PMC
would like to start the release process next week, so please test any
supported
On 3/4/15, 8:18 AM, "Alberto Massari" wrote:
>first of all, thank you for taking care of the release; I compiled the
>source on Windows using VC9, VC11 and VC12; I have noticed that the
>solution file for VC12 is missing the correct version, so it is opened
>by VC11. I will be fixing this sho
On 3/4/15, 10:42 PM, "Denis Excoffier" wrote:
>Hi,
>
>Compiled successfully and somewhat tested on Cygwin 32 bits (1.7.35),
>Solaris 10, Linux 32 bits Ubuntu, and Darwin Yosemite (10.10.2).
>
>It seems that you forgot the following one:
Is there a bug filed on it? If so I just missed it when
I've uploaded a second beta of Xerces-C 3.1.2 [2] containing a couple of
small fixes (VS2012 solution file fix, a backport of an XMLString
binToText bug reported yesterday) and a tweak to the automake settings so
I can generate a ZIP distribution from make dist.
Just want to keep the test sourc
On 3/6/15, 4:17 AM, "Gareth Reakes" wrote:
>
>On OSX compiles fine but test run produces this attached failure diff.
Compared to 3.1.1 you mean?
How do the tests get run as a unit? Do you know which test is giving that
different result?
-- Scott
--
On 3/6/15, 9:34 AM, "Gareth Reakes" wrote:
>No, compared to the committed test output file -
>scripts/sanityTest_ExpectedResult.log
Ok, I'll look at when that was committed.
>make check
So it runs them as part of the test build? Ok, I didn't notice that, will
review that.
-- Scott
---
On 3/6/15, 9:34 AM, "Gareth Reakes" wrote:
>
>On OSX compiles fine but test run produces this attached failure diff.
Somewhat surprisingly, on my OS X laptop, my test run has identical output
to what's checked in, no diff. But I did that out of subversion, not the
tarball, so I'll rerun the che
In case it matters, this is what I'm using with configure:
configure: Report:
configure: File Manager: POSIX
configure: Mutex Manager: POSIX
configure: Transcoder: icu
configure: NetAccessor: socket
configure: Message Loader: inmemory
Any of those different in your build that's giving
On 3/6/15, 10:08 AM, "Gareth Reakes" wrote:
>
>Do you have the file in your checkout?
>
>/xerces-c-3.1.2/samples/data/long.xml
No, it's not in the dist target, so that's the problem. I'll add it and
republish a third beta today.
One of the things I'm trying to clean up is the dist. It was quit
A third beta with the missing test file added is now available [1]. The
test output now matches the output checked in as a baseline.
-- Scott
[1] https://people.apache.org/~scantor/
On 3/6/15, 10:58 AM, "Gareth Reakes" wrote:
>
>Are you still getting that seg fault Scott? Which test?
No, should have clarified that sorry, I just didn't know how the tests were run
or that you had a real script to run them. I was running them by hand without
knowing what parameters to give th
On 3/6/15, 11:07 AM, "Gareth Reakes" wrote:
>
>Great. So looks like tests all pass with expected results.
Yes, at least in this case. Anybody building elsewhere, it would be good to run
that same check of course.
-- Scott
On 3/9/15, 3:54 PM, "Denis Excoffier" wrote:
>
>Would it be feasible to also include the documentation (the doc folder,
>like under xerces-c-3.1.1)?
I didn't recall the old source distribution including the API docs, but I see
it's there, I just didn't run doxygen. I'll make sure the final inclu
I have prepared a hopefully-final distribution for testing [1] as a release
candidate. The filenames are identical to the eventual release.
I fixed the distribution last night to include all missing content that was
present in the 3.1.1 distribution, including the HTML site and API docs. If
any
> Not missing ones i guess but extra ones. I suppose the following files should
> not be present in the gz and bz2 distributions:
>
> m4/._libtool.m4
> m4/._ltoptions.m4
> m4/._ltsugar.m4
> m4/._lt~obsolete.m4
I hadn't actually found where they came from. Might be a Mac thing. Probably
not worth
> Does automake support it? I guess I can add that and rebuild another RC if
> it's
> important enough.
(For context, the only reason I added bz2 was that I package this for some SUSE
platforms, and they're probably going to start warning me at the build service
about not having bz2 sources.)
On 3/11/15, 1:41 PM, "Cantor, Scott" wrote:
>
>> By the way, could we please also get a xerces-c-3.1.2.tar.xz distribution, in
>> addition to or instead the bz2 distribution?
>
>Does automake support it? I guess I can add that and rebuild another RC if
>it'
I haven't seen any concerns, so are we ready to vote on this?
-- Scott
A hopefully-final distribution set is now posted [1].
No code changes have occurred since the second beta posting last week, but
various distribution tweaks and changes to the doc/ content for generation of
the web site have been made.
I believe this is now ready for the PMC to conduct a vote f
My committer's +1
-- Scott
On 3/18/15, 11:28 AM, "Gareth Reakes" wrote:
>Hey guys,
>
> Here is my +1.
On 3/18/15, 4:02 PM, "Alberto Massari" wrote:
>Here's my +1 too. And also my thanks to Scott for the time spent in
>arranging this release.
You're welcome.
Just following up to say that I'll be doing the actual formal release tomorrow
(various timing/scheduling factors make that the best choi
On 3/18/15, 4:30 PM, "Denis Excoffier" wrote:
>
>When i compare the first RC and the second RC (current), i observe some
>improvement in the doc/ and samples/ folders, but also that
>- config.guess has timestamp='2013-05-16' (RC2) instead of
>timestamp='2014-11-04' (RC1)
>- config.sub has timest
On 3/18/15, 5:04 PM, "Michael Glavassevich" wrote:
>
>Got to give folks time to vote. Normally suggested that these run for 72
>hours [1] before tallying them up. It's only been 6 hours on this one.
I will await the PMC's decision. I was operating based on off-line discussion.
-- Scott
> Thanks again Scott.
Ok, unfortunately I'm deep into the bowels of my software release at the
moment, and OpenSSL just screwed me royally by adding to the 1.0.2 ABI in
1.0.2a, so that's costing me a nice chunk of today.
I may get to the release late afternoon or tonight, hopefully, and if not
The Xerces project has released a patch update, V3.1.2, and it is now available
on the web site.
The list of bug fixes is available from Jira [1].
The web site has been updated with the new release. There are a few minor
changes needed to pages here and there, which I will complete clean up on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
CVE-2015-0252: Apache Xerces-C XML Parser Crashes on Malformed Input
Severity: Important
Vendor: The Apache Software Foundation
Versions Affected: Apache Xerces-C XML Parser library versions
prior to V3.1.2
Description: The Xerces-C XML parser m
I believe I've corrected the few bugs I noticed with the web site, and all of
the web site content is now checked into the branch, including the security
advisory.
A blocker task is recorded noting that a trunk release should copy that content
over as part of prepping it.
I have added a note t
On 6/16/15, 3:54 AM, "thosaratu...@gmail.com on behalf of Atul Thosar"
wrote:
>
>From archives/google, I believe Xerces should work on Solaris 11 platform. But
>has anyone actually tried/ran it on Solaris 11?
A supported version, yes.
>One more scenario I would to clarify/discuss – Currently
On 6/16/15, 1:05 PM, "thosaratu...@gmail.com on behalf of Atul Thosar"
wrote:
>Btw Could you please help me to understand in what sense 2.8 is insecure?
In the sense that it has security bugs that are fixed, such as [1]. There are
undoubtedly others.
-- Scott
[1] http://xerces.apache.org/xer
On 7/8/15, 6:07 AM, "rle...@codelibre.net" wrote:
>
>I didn't see any response to this unless I missed it.
There is very little active energy around this project, you'll get a sense of
that from the list archives.
>The following patch demonstrates a possible fix for VC12, which should
>apply
I'm starting to work on a bug fix release and while I'll review Jira and some
notes I have saved up, this is just a general heads up in case anything
pressing and small can be identified to fix.
Timeline for this is probably mid-Feb or so.
-- Scott
> I would like to ask which is the file structure for xerces-c_3_1.dll that has
> been successful built after following steps described here
>
> https://xerces.apache.org/xerces-c/build-3.html
The solutions for MSVC at least build to the Build directory (with subsequent
nesting based on what bui
I've built a release candidate of xerces-c-3.1.3 for testing. This is a bug fix
release to address some reported issues and I am targeting late February for
the PMC to approve the release.
I noted there's a dev/ tree in the dist.apache.org svn repository, though I
haven't located a URL that map
I have (finally) gotten the updated release posted [1]. The web site should be
updated now; if any site errors are spotted, report them and I'll get them
fixed.
-- Scott
[1] http://xerces.apache.org/xerces-c/download.cgi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
CVE-2016-0729: Apache Xerces-C XML Parser Crashes on Malformed Input
Severity: Critical
Vendor: The Apache Software Foundation
Versions Affected: Apache Xerces-C XML Parser library versions
prior to V3.1.3
Description: The Xerces-C XML parser mis
> Did someone manage to get xerces build with MSVC 2015?
Yes, I checked in solution files that are mostly working the other day.
-- Scott
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-
Question to the rest of the remaining developers: is it an ABI change to add
error messages/codes? I'm not familiar enough with the error handling machinery
to know what's entailed in adding one, though I know there's an enum, and an
XML file that's used to produce all the source code with the e
> Unless the decorated name of the enum includes the number of values, it
> should not change, and the ABI stays the same.
> It may require that the developer handle the new error code, but I doubt
> that it happens very often. So, I think a 3.1.4 release is ok.
I was more concerned about all the
I have prepared a release candidate for 3.1.4 that fixes some outstanding bugs.
My ETA for release is around the end of the month. I haven't checked over the
generated HTML pages in the tarballs yet, so I probably will do a second RC
before calling for a vote maybe around the end of next week, j
> How DOM presentation of XML document can be serialized into string in
> JSON format and opposite?
Well, a) that's not a well-defined mapping, and b) there's no code in Xerces to
do that if that's what you're asking. If there's any library using Xerces under
it that does this, I wouldn't know
I've done a bit of minor cleanup (removing .svn detritus) and posted new
artifacts with signatures:
https://dist.apache.org/repos/dist/dev/xerces/c/3/sources/
I would like to call for a vote by the PMC to release V3.1.4.
This is my +1
-- Scott
> Couldn't you find a more recent config.guess? See for example the one in
> gcc-6.1.0.tar.bz2, dated 2016-01-01.
I built it on Red Hat 7. I assume autoreconf pulls in whatever is there.
-- Scott
-
To unsubscribe, e-mail: c-de
With several +1 votes and no objections, the vote has passed and I will
finalize the release tomorrow morning.
Thanks,
-- Scott
> -Original Message-
> From: Cantor, Scott
> Sent: Wednesday, June 22, 2016 12:32 PM
> To: c-dev@xerces.apache.org
> Subject: Call for vote
&
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
CVE-2016-4463: Apache Xerces-C XML Parser Crashes on Malformed DTD
Severity: Important
Vendor: The Apache Software Foundation
Versions Affected: Apache Xerces-C XML Parser library versions
prior to V3.1.4
Description: The Xerces-C XML parser fai
A patch release of the Xerces-C XML parser is now available and is propagating
to the mirrors. It includes a small number of important bug fixes, including a
fix for CVE-2016-4463.
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10510&version=12336069
Of special note, applicati
> FYI, the downloads on http://apache.org/dist/xerces/c/3/sources/
> are missing the signatures and checksums for xerces-c-3.1.4.tar.xz.
> Would it be possible to add them?
Forgot it existed. I'll try and get to it when I can.
-- Scott
--
> Attached is a diff against 3.1.4 to enable building with VC12 and VC14
> with the ICU configurations.
I assume that's already in Jira. If not, it's not going to ever get remembered
and applied.
-- Scott
-
To unsubscribe, e-m
On 7/13/16, 10:11 AM, "Gobbur, Pratima" wrote:
> I need the source code for 2.7.0 to check if there was any customisation on
> our side.
http://svn.apache.org/viewvc/xerces/c/tags/Xerces-C_2_7_0/
-- Scott
-
To unsubscribe,
> We are now wondering if Xerces-C++ devs are happy for us to upload this
> package to www.nuget.org and, if so, whether there are any specific
> guidelines we should follow or clauses to be aware of in order to do this
> (aside from clearly indicating the obvious bits, regarding who is the true
>
> Our intention is to specifically use this platform to deliver the Xerces-C++
> 3.1.2 NuGet package that we have put together so that users of DNV GL -
> Energy software products can have access to it in a public and easily
> accessible repository. We would clearly indicate that the package has be
> I had a transcoding problem with Xerces-C and noticed that it has
> already been described
> https://issues.apache.org/jira/browse/XERCESC-2052 and fixed for more
> than a year but not in the 3.1 branch.
> So I took the liberty to port the fix and would be happy if it could be
> released in a (ho
> So just for the record, the error is really a regression, it worked in
> 3.1.1 and the fix in trunk was this commit:
That's even stronger evidence that I have no business touching that code, I'm
afraid. So I would have to say that somebody who does know it needs to own it
and take care of appl
> Does somebody know when it will be fixed in official patch?
Months ago?
http://svn.apache.org/viewvc?view=revision&revision=1747619
Red Hat still hasn't backported it to my knowledge.
-- Scott
-
To unsubscribe, e-mail: c-de
> > Does somebody know when it will be fixed in official patch?
>
> Months ago?
>
> http://svn.apache.org/viewvc?view=revision&revision=1747619
Meant to link to advisory.
http://xerces.apache.org/xerces-c/secadv/CVE-2016-4463.txt
> -- Scott
--
> Hi Scott,
> I checked Xerces 3.1.4 sources(
> src/xercesc/validators/DTD/DTDScanner.cpp)
>
> The fix is missing in them.
> const XMLCh nextCh = fReaderMgr->peekNextChar();
> calls without try catch .
The fix I intended to aply is in 3.1.4 and I just verified that.
-- Scott
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
> 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
> 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
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 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, a
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.
>
I've completed the comparison in both directions and nothing really new has
popped up as a concern, just the two trunk changes I identified (repeated here
for emphasis):
r1517488 (XERCESC-2016)
r1528170 (XERCESC-2019)
There are a number of fixes to port up to the trunk, at least one needing a
Just correcting subject line and branch version.
-- Scott
> -Original Message-
> From: Cantor, Scott [mailto:canto...@osu.edu]
> Sent: Monday, May 1, 2017 1:18 PM
> To: c-dev@xerces.apache.org
> Subject: Status of trunk / main-3.3 comparison
>
> I've comple
> Try to replace this (and if it works other similar) function with:
>
> template
> static inline DOMNodeImpl*
> castToNodeImpl(const T* p)
> {
> return &p->fNode;
> }
Yeah, I was considering but wasn't sure if we wanted to add templates in, are
we using them anywhere else in the code base? A
> 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
> 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
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
-
> 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
> 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 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 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
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 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
> I'd be very interested in any thoughts anyone had on this topic. I've
> opened a ticket for it here along with an initial testable
> implementation for anyone who wanted to try it out:
I'm definitely going to take a look at it for my own projects since we don't
have this at present for our nat
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
I've ported essentially all code-related changes and a decent amount of the web
site changes from the 3.1 branch back up to trunk.
At least one of the original security fixes to the branch apparently caused a
regression, which I wasn't surprised by. I think there's a separate bug open on
that,
On 6/29/17, 3:02 PM, "Roger Leigh" wrote:
> The recent trunk changes broke a few of the unit tests.
I don't understand how, other than the ones that are for some reason depending
on the output of the parameter options for the DOMCount sample. That seems like
an odd test, but it certainly would
1 - 100 of 242 matches
Mail list logo
