I am also in favor of keeping SVN 2geom in. I see these options: 1. keep 2geom separate and let people build a new 2geom when necessary 2. put 2geom into folder in inkscape 2a. build together with inkscape 2b. build separately (same as 1, without the separate svn up)
2b. seems redundant to me. 1. is like it is now (note that 2geom's API doesn't change that often, svn upping is perhaps more related to bugfixes; but I cannot forsee the future. In the past there were some API additions that LPE needed and that would give compile errors for inkscape without them.) 2a. needs a bit of work: 2geom uses cmake, I do not know how easy it is to merge it with inkscape's build process (perhaps only a system call "./lib2geom/make install" ?)
-johan
john cliff:
On 7/23/07, Aaron Spike <aaron@...749...> wrote:
Bryce Harrington wrote:
That said, I think if you wish to merge this branch into main, it would be wisest to make your code only relies on a
released version
of lib2geom (which may mean working to get a release of lib2geom.)
Such a requirement is going to force lib2geom to release
new versions
weekly or even more rapidly. :-) I think requiring a stable
version of
lib2geom for a release version of Inkscape is a great idea
but at the
current moment requiring a stable version of lib2geom for a development version of Inkscape is impractical at this point in its development. I'm pretty sure we could get a new stable release of lib2geom today if we needed it. But I imagine that stable
release will
soon be too old for Inkscape's needs. My vote is for merging and requiring a lib2geom from svn trunk and publishing and updating the minimum necessary revision in the wiki. The projects need
to push each
other right now. Perhaps in a month we will be ready to
require a stable version of lib2geom.
Aaron Spike
I'd vote for the SVN import stuff, so lib2geom looks like another folder in the inkscape tree, then merge it into the inkscape build process. I dont think needing the SVN version of Lib2Geom for the SVN version of inkscape is inappropriate, if the guys had done the development of it in a folder in the inkscape tree we'd have had no problem calling the unstable code then, I dont see why them wanting to make it a library in its own right thats useful for non inkscape purposes too should change what we require in terms of stability / release level when we're still mid dev cycle. Its not like its a project we have no connection too... Agreed tho we want a release to freeze the state inline with our release.