Re: Integrating CMake support for xerces

[Roger Leigh]

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 dismiss that one.


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?


I'm getting a few conflicts in EXTRA_DIST in a few Makefile.ams. 
Nothing major, but it's highlighting that there's stuff missing on the 
trunk.



Since the proposed changes don't touch any of the existing build
systems, merging onto the 3.1 branch would be safe, but since it's a
fairly large change it would be understandable to leave this for a new
minor release.  Is there any particular preference?


I think there's a relevant parallel discussion about the project's next step. 
Right now there are some apparent regressions on the branch I introduced trying 
to fix security issues in code I didn't understand. And there are some 
outstanding security issues on both branches because of that DOMHelper code 
that's making in-memory object layout assumptions with improper casts. That has 
got to be fixed.

Meanwhile, Red Hat has refused to ship existing security fixes in their copy of 
3.1, which is leaving my customers screwed, and that's becoming intolerable.

My only practical solution to fix that is to get my software rebased onto a new 
version, 3.2, which I can ship in a non-conflicting package. 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.

So given that, I suspect the thing to do is to put it on trunk, but I'd like a 
bit of time to review current trunk before we do that merge so I'm not dealing 
with both at once if that's ok.


OK.  If there's anything I can do to help out here, I can certainly try.


Regards,
Roger

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[Cantor, 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 changes don't touch any of the existing build 
> systems, merging onto the 3.1 branch would be safe, but since it's a 
> fairly large change it would be understandable to leave this for a new 
> minor release.  Is there any particular preference?

I think there's a relevant parallel discussion about the project's next step. 
Right now there are some apparent regressions on the branch I introduced trying 
to fix security issues in code I didn't understand. And there are some 
outstanding security issues on both branches because of that DOMHelper code 
that's making in-memory object layout assumptions with improper casts. That has 
got to be fixed.

Meanwhile, Red Hat has refused to ship existing security fixes in their copy of 
3.1, which is leaving my customers screwed, and that's becoming intolerable.

My only practical solution to fix that is to get my software rebased onto a new 
version, 3.2, which I can ship in a non-conflicting package. 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. 

So given that, I suspect the thing to do is to put it on trunk, but I'd like a 
bit of time to review current trunk before we do that merge so I'm not dealing 
with both at once if that's ok.

> For maintenance reasons, I'd like to propose removing all the Visual Studio 
> files; this was one of the primary reasons for developing the CMake 
> support in the first place.  This would make sense to do on the 
> trunk/3.2 branch, since we wouldn't want to remove existing 
> functionality on the 3.1 branch.

Right, I think that's another good argument for using trunk.

> Removing the Autoconf support would also be a possibility if there was 
> consensus to do so.  The CMake support certainly implements all the 
> Autoconf features--it reproduces every single feature test and option 
> exactly.  But the maintenance cost is vastly less than the Visual Studio 
> support, so retaining both Autoconf and CMake support is certainly possible.

I'm not inclined to consider removint autoconf without seeing the alternative 
and understanding the implications, particularly wrt libtool.

> 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

I will do so when I can.

-- Scott