Hi Bruno, I'm sorry for your recompile waiting times, but it's unavoidable pain I'm afraid.
To fix your problem, you probably just need to rebuild the dependency graph (btool.dep), so do a del *.dep btool -j and then it should work.
About the compile time: 2 hours is *really* long. What PC are you working on? Does your processor have multiple cores? If so, you can compile with multiple threads: compile buildtool.cpp with -fopenmp and run btool with the "-j" option. For reference, for me a clean build takes about 5 minutes (core-i7, max threads).
regards, Johan
---- "Bruno Winck wrote:
Hi All,
I was happy when I started that the project was building flawlessly.
Alas I made the error to do a "bzr update" before start working. After waiting 2 hours until the whole project recompile due to a change in src/2geom/affine.h After fixing my own compilation errors I'm now spending trying to understand why it's looking for an absent "src/2geom/svg-path.cpp" (there is such a file in svg sub directory) Did multiple "bzr update" hoping it would fix it Eventually I created an empty "svg-path.cpp" (you never know if it was just dropped replacing by empty one would do the trick).
I got the undefined below So now I'm stucked.
PS: You can split a large project into dlls and like this save a _lot_ of the time of the contributors.
" F:\Libs\devlibs/bin/libxml2.dll F:\Libs\devlibs/bin/libxslt.dll Make error line 437: LINK problem: build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.text$_ZN4Geom16PathIteratorSinkISt20b ack_insert_iteratorISt6vectorINS_4PathESaIS3_EEEED1Ev[Geom::PathIteratorSink<std::back_insert_iterator<std::vector<Geom::Path, std ::allocatorGeom::Path > > >::~PathIteratorSink()]+0x2e): undefined reference to `vtable for Geom::PathSink' build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.text$_ZN4Geom16PathIteratorSinkISt20back_insert_iteratorISt6vectorINS_4P athESaIS3_EEEED1Ev[Geom::PathIteratorSink<std::back_insert_iterator<std::vector<Geom::Path, std::allocatorGeom::Path > > >::~Pat hIteratorSink()]+0x5d): undefined reference to `vtable for Geom::PathSink' build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.text$_ZN4Geom16PathIteratorSinkISt20back_insert_iteratorISt6vectorINS_4P athESaIS3_EEEED0Ev[Geom::PathIteratorSink<std::back_insert_iterator<std::vector<Geom::Path, std::allocatorGeom::Path > > >::~Pat hIteratorSink()]+0x2e): undefined reference to `vtable for Geom::PathSink' build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.text$_ZN4Geom16PathIteratorSinkISt20back_insert_iteratorISt6vectorINS_4P athESaIS3_EEEED0Ev[Geom::PathIteratorSink<std::back_insert_iterator<std::vector<Geom::Path, std::allocatorGeom::Path > > >::~Pat hIteratorSink()]+0x61): undefined reference to `vtable for Geom::PathSink' build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.text$_ZN4Geom16PathIteratorSinkISt20back_insert_iteratorISt6vectorINS_4P athESaIS3_EEEED2Ev[Geom::PathIteratorSink<std::back_insert_iterator<std::vector<Geom::Path, std::allocatorGeom::Path > > >::~Pat hIteratorSink()]+0x2e): undefined reference to `vtable for Geom::PathSink' build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.text$_ZN4Geom16PathIteratorSinkISt20back_insert_iteratorISt6vectorINS_4P athESaIS3_EEEED2Ev[Geom::PathIteratorSink<std::back_insert_iterator<std::vector<Geom::Path, std::allocatorGeom::Path > > >::~Pat hIteratorSink()]+0x5d): more undefined references to `vtable for Geom::PathSink' follow build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.rdata$_ZTVN4Geom11PathBuilderE[vtable for Geom::PathBuilder]+0x34): unde fined reference to `Geom::PathSink::pathvector(std::vector<Geom::Path, std::allocatorGeom::Path > const&)' build\obj\2geom\sbasis-to-bezier.o:sbasis-to-bezier.cpp:(.rdata$_ZTVN4Geom16PathIteratorSinkISt20back_insert_iteratorISt6vectorINS _4PathESaIS3_EEEEE[vtable for Geom::PathIteratorSink<std::back_insert_iterator<std::vector<Geom::Path, std::allocatorGeom::Path
]+0x34): undefined reference to `Geom::PathSink::pathvector(std::vector<Geom::Path, std::allocatorGeom::Path > const&)'
build\obj\extension\internal\metafile-print.o:metafile-print.cpp:(.text+0xc97): undefined reference to `vtable for Geom::PathSink'
build\obj\extension\internal\metafile-print.o:metafile-print.cpp:(.text+0xd05): undefined reference to `vtable for Geom::PathSink'
build\obj\extension\internal\metafile-print.o:metafile-print.cpp:(.text+0x1066): undefined reference to `vtable for Geom::PathSink ' build\obj\extension\internal\metafile-print.o:metafile-print.cpp:(.text+0x12fb): undefined reference to `vtable for Geom::PathSink ' build\obj\extension\internal\metafile-print.o:metafile-print.cpp:(.text+0x1369): undefined reference to `vtable for Geom::PathSink ' build\obj\sp-ellipse.o:sp-ellipse.cpp:(.text+0x2aa7): more undefined references to `vtable for Geom::PathSink' follow collect2: ld returned 1 exit status "
Bruno Winck Email: bwinck@...2632... Blog: http://www.kneaver.com/blog
Kneaver Corp http://www.kneaver.com/ Twitter:http://twitter.com/kneaver PH: +(415) 335-6932
-----Original Message----- From: Bruno Winck, Kneaver [mailto:bw@...2632...] Sent: Tuesday, January 14, 2014 8:29 AM To: Martin Owens Cc: 'Jelle Mulder'; inkscape-devel@lists.sourceforge.net Subject: RE: [Inkscape-devel] External CSS support {Spam?}
True but this bug is a totally different beast.
Simply add a flag to styles to differentiate those that need to be persistent and others. Or better maintain two lists : styles defined on the element and styles computed.
Because there is a question of priority with styles. Styles corresponding to largest class matching will have the highest priority. Inline styles having the upmost priority. So styles defined are copied to styles computed _after_ all rules applied.
I'm kind of surprised that libcroco don't support all that.
-Bruno
Bruno Winck Email: bwinck@...2632... Blog: http://www.kneaver.com/blog
Kneaver Corp http://www.kneaver.com/ Twitter:http://twitter.com/kneaver PH: +(415) 335-6932
-----Original Message----- From: Martin Owens [mailto:doctormo@...400...] Sent: Monday, January 13, 2014 10:24 PM To: Bruno Winck, Kneaver Cc: 'Jelle Mulder'; inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] External CSS support {Spam?}
On Mon, 2014-01-13 at 18:51 +0530, Bruno Winck, Kneaver wrote:
As far as performance is concerned my change has little impact. I'm just creating a SPStyleElem before the root from the PI and apply it before. If there is no style in PI nothing is changed. As mentioned in some comments in the code 2 traversals would be desirable to be sure all styles fragments are available before the display traversal or as some browsers are doing is to restart the traversal whenever styles are affecting the traversal.
There is one other bug that we need to be concerned with:
https://bugs.launchpad.net/inkscape/+bug/167937
This means that styles applied from an external css would be applied into the element's style when we save the svg. Which would reduce the usefulness of it.
Best Regards, Martin Owens
CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel