Committing LivePathEffects to trunk
Hello all,
I want to get LivePathEffects (LPE) into trunk soon. The benefit of having my own branch (i.e. few people build it, so highly unstable code is no prob ;-) ; thanks for testing guys!!!) is starting to become a drawback (i.e. I'd like people to use it and report bugs/problems/RFE's)
There is a problem though: Dependencies. LPE needs lib2geom (this is a *good* thing!), which needs Boost.
1. I don't think Boost is going to be a big problem. Well... it is big, but 2geom does not use that many headers; i have to check but only a small part of boost is necessary i think. 2. lib2geom does not have an official release and LPE uses the latest SVN version. Development is very active, often providing new features InkscapeLPE wants. This basically means that to build LPE, one first must svn up 2geom and make install it.
A. What are your thoughts on the dependency issues?
B. Now I think of it, I think the file-format extension introduced by LPE must be agreed upon as well. It is SVG compatible and not very intrusive but still...
Kind regards, Johan
On 7/23/07, Johan Engelen <j.b.c.engelen@...1578...> wrote:
B. Now I think of it, I think the file-format extension introduced by LPE must be agreed upon as well. It is SVG compatible and not very intrusive but still...
Hmm, can you please elaborate on this? What do you need a new file format for?
From: bulia byak [mailto:buliabyak@...400...]
On 7/23/07, Johan Engelen <j.b.c.engelen@...1578...> wrote:
B. Now I think of it, I think the file-format extension
introduced by
LPE must be agreed upon as well. It is SVG compatible and not very intrusive but still...
Hmm, can you please elaborate on this? What do you need a new file format for?
Sorry, I did not mean a new file format but an 'extension'. (incidentally, now i know what i think you read: a new extension like .johan or something?) I meant that LPE adds new stuff to the Inkscape SVG files. Specifically: In the <defs> section, it adds inkscape:path-effect, for example: <inkscape:path-effect effect="gears" id="path-effect2210" phi="5" teeth="10" /> For shapes it adds inkscape:path-effect and inkscape:original-d attributes, for example: <path d="..." id="path2208" inkscape:path-effect="#path-effect2210" inkscape:original-d="..." />
-johan
On 7/23/07, J.B.C.Engelen@...1578... <J.B.C.Engelen@...1578...> wrote:
Sorry, I did not mean a new file format but an 'extension'. (incidentally, now i know what i think you read: a new extension like .johan or something?) I meant that LPE adds new stuff to the Inkscape SVG files. Specifically: In the <defs> section, it adds inkscape:path-effect, for example: <inkscape:path-effect effect="gears" id="path-effect2210" phi="5" teeth="10" /> For shapes it adds inkscape:path-effect and inkscape:original-d attributes, for example: <path d="..." id="path2208" inkscape:path-effect="#path-effect2210" inkscape:original-d="..." />
Ah, then I think that's perfectly OK :)
On 7/23/07, Johan Engelen wrote:
- lib2geom does not have an official release
Always check facts :)
http://sourceforge.net/project/showfiles.php?group_id=167845
Alexandre
Alexandre Prokoudine wrote:
On 7/23/07, Johan Engelen wrote:
- lib2geom does not have an official release
Always check facts :)
http://sourceforge.net/project/showfiles.php?group_id=167845
Aargh! I *did* check http://lib2geom.sourceforge.net/ :-( Thanks Alexandre for correcting me :)
I'll rephrase then: lib2geom does have an official release (very cool guys!), however InkscapeLPE needs 2geom newer than svn rev.988 of 7 Juli 2007.
-Johan
On Mon, Jul 23, 2007 at 04:46:51PM +0200, Johan Engelen wrote:
- lib2geom does not have an official release and LPE uses the latest
SVN version. Development is very active, often providing new features InkscapeLPE wants. This basically means that to build LPE, one first must svn up 2geom and make install it.
A. What are your thoughts on the dependency issues?
There is an 'SVN Externals' function that allows hooking together two SVN repositories, such that when you svn up in one, it svn ups the other too.
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.)
Bryce
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
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.
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.
I'd personally favor putting a (statically-linked) _copy_ of lib2geom in the Inkscape tree for now. The 2geom API will not be entirely stable for a while, so I think it would be best if inkscape and 2geom updates were decoupled for now. Periodically, we can refresh the version of 2geom in the inkscape tree and do any integration work necessary to make Inkscape work with the new version.
Using something like svn:externals is simply a recipe for frequent and arbitrary breakage.
Eventually we should be able to switch to using an installed specific release of lib2geom, once it gets better distributor uptake.
-mental
On Mon, Jul 23, 2007 at 12:31:39PM -0500, Aaron Spike 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.
You trimmed it out, but I said this could be achieved with svn extern.
I never said making it depend on released versions was a requirement, just that it would be a wiser approach. But please note that linking svn's ALSO places a burden on lib2geom in that it would instead require that lib2geom svn remain always buildable. In theory that should not ever be an issue, but imagine if a build issue does enter into lib2geom; since only lib2geom developers with commit access to that project's svn would be able to fix it, it could result in a situation where inkscape development would effectively grind to a halt waiting for a fix.
Of course, this will likely never happen because lib2geom developers would never commit build errors into svn. It is fortunate that a few inkscape developers have commit access into lib2geom; hopefully they will take the responsibility of quickly fixing issues if they are identified, and this issue will never become a problem.
I imagine there could also be other potential glitches. Both projects use different svn providers, so now instead of just relying on inkscape svn being functional, we now require two svn servers to be up and functioning at the same time. And so on. In theory, everything will work perfectly, but in practice...
This is why I feel that when possible, it is wiser to rely on stable releases. This doesn't mean forcing upstream to release frequently; it means being organized in when features are rolled out that require features only available in the upstream SVN. It's the same philosophy we would apply with relying on cairo, gtkmm, or other upstream library changes. If everyone feels that it is not possible to apply this philosophy in this case, well then this would be an allowable exception.
To be honest it doesn't really matter to me; I've been too busy with the new job to work on Inkscape anyway. If those who are actively developing on this are willing to experiment with linking svn's with an external project, then if the above concerns are legitimate, I'm sure they'll make themselves clear and people can deal with them then. Patch first, discuss later as we always say. ;-)
Bryce
Bryce Harrington wrote:
On Mon, Jul 23, 2007 at 12:31:39PM -0500, Aaron Spike 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.
You trimmed it out, but I said this could be achieved with svn extern.
Yes, I trimmed it on purpose. Starting with svn extern seems like a premature optimisation to me. Aditionally I've never used svn extern before and I wouldn't feel comfortable trying it for the first time on a project like Inkscape. So my vote goes for two separate svn checkouts.
I never said making it depend on released versions was a requirement, just that it would be a wiser approach.
I agree it is wisest.
But please note that linking svn's ALSO places a burden on lib2geom in that it would instead require that lib2geom svn remain always buildable. In theory that should not ever be an issue, but imagine if a build issue does enter into lib2geom; since only lib2geom developers with commit access to that project's svn would be able to fix it, it could result in a situation where inkscape development would effectively grind to a halt waiting for a fix.
Of course, this will likely never happen because lib2geom developers would never commit build errors into svn. It is fortunate that a few inkscape developers have commit access into lib2geom; hopefully they will take the responsibility of quickly fixing issues if they are identified, and this issue will never become a problem.
I could be wrong but I think all of the lib2geom developers have commit access to both projects. I have personally witnessed times when both lib2geom developers and inkscape developers have made unbuildable commits. It is going to happen. But I think grinding halts will be much rarer occasions (only when one of us makes an unbuildable commit and then goes on vacation).
I hope we can get more inkscape developers involved in lib2geom. Actually more developers period.
I imagine there could also be other potential glitches. Both projects use different svn providers, so now instead of just relying on inkscape svn being functional, we now require two svn servers to be up and functioning at the same time. And so on. In theory, everything will work perfectly, but in practice...
Both projects use sourceforge svn; we'll be down at the same time.
This is why I feel that when possible, it is wiser to rely on stable releases. This doesn't mean forcing upstream to release frequently; it means being organized in when features are rolled out that require features only available in the upstream SVN. It's the same philosophy we would apply with relying on cairo, gtkmm, or other upstream library changes. If everyone feels that it is not possible to apply this philosophy in this case, well then this would be an allowable exception.
Development will grind to a halt while we wait for the next lib2geom release to fix a bug in the new feature we want to commit. I think this stance is necessary with large established projects like gtkmm and cairo. They have their own culture and established release systems. But at the same time I do feel that we are hindered slightly sometimes as we wait for fixes and features to come back downstream to us (waiting not because those projects are sluggish, but because we lack a strong inkscape advocate as an involved party). Lib2geom shares much Inkscape culture and I imagine they will be rather flexible to work with us in syncing release etc.
To be honest it doesn't really matter to me; I've been too busy with the new job to work on Inkscape anyway. If those who are actively developing on this are willing to experiment with linking svn's with an external project, then if the above concerns are legitimate, I'm sure they'll make themselves clear and people can deal with them then. Patch first, discuss later as we always say. ;-)
Is it possible to compromise? Can we strive to depend on a released lib2geom as much as possible but allow minimal well publicised periods of dependance on svn? or is that too much complication?
Aaron
participants (8)
-
unknown＠example.com -
Aaron Spike -
Alexandre Prokoudine -
Bryce Harrington -
bulia byak -
Johan Engelen -
john cliff -
MenTaLguY