Build broken (gtkm 2_24)...
Hi all, I just fixed the windows build. With the current devlibs, we need "#define WITH_GTKMM_2_24".
If this is not correct than please revert devlibs first. Verify the revert using the online launchpad tool, then fix build.xml.
Ciao, Johan
Hi,
De : Johan Engelen <jbc.engelen@...2592...> I just fixed the windows build. With the current devlibs, we need "#define WITH_GTKMM_2_24".
No. I've had to uncommit the recent changes in the devlibs (due to [false] regressionbug #1070903 "Crash when saving a new document" and [true] regression Bug #1069806 "Inkscape crash in File>Open") and we're currently back to revision 35, with gtkmm2.22. Sorry if I forgot to notify the list.
FYI, I've added a new devlibs-testing branch that you can use to test the gtkmm2.24 stack (see https://code.launchpad.net/~jazzynico/inkscape-devlibs/devlibs-testing). Apart from Bug #1069806, I haven't noticed any regression, but since I use Windows for testing only (my computers are on Ubuntu and Crunchbang) and it's the first time I build dlls, I may have missed something, and thus some help from Windows users would be welcome.
-- Nicolas
On 28-10-2012 8:19, Nicolas Dufour wrote:
Hi,
De : Johan Engelen <jbc.engelen@...2592...> I just fixed the windows build. With the current devlibs, we need "#define WITH_GTKMM_2_24".
No. I've had to uncommit the recent changes in the devlibs (due to [false] regressionbug #1070903 "Crash when saving a new document" and [true] regression Bug #1069806 "Inkscape crash in File>Open") and we're currently back to revision 35, with gtkmm2.22. Sorry if I forgot to notify the list.
We are currently on rev35 with gtk+ 2.24.10 according to your last commit message. The devlibs readme.txt says gtkmm 2.24.2. Check the revision history *online* (note that bazaar is... well......). There is no un-commit there. If un-committing does not show up in the history online, we should never do such a bzr (bizarre) action.
Fact is that the build was broken on Windows. And that had nothing to do with devlibs rev35. We build with #define GDKMM_DISABLE_DEPRECATED (/include/gdkmm-2.4/gdkmm/window.h) so we need #define WITH_GTKMM_2_24 too to use get_width instead of get_size in /src/ui/widget/preferences-widget.cpp.
- Johan
De : Johan Engelen <jbc.engelen@...2592...>
We are currently on rev35 with gtk+ 2.24.10 according to your last commit message.
Exact.
The devlibs r35 readme.txt says gtkmm 2.24.2. Check the revision history *online*
http://bazaar.launchpad.net/~inkscape.dev/inkscape-devlibs/trunk/view/head:/... says gtkmm 2.22.0
(note that bazaar is... well......). There is no un-commit there. If un-committing does not show up in the history online, we should never do such a bzr (bizarre) action.
Well, yes, maybe I should have reverted the changes by committing a rev. 37. Uncommitting seems to remove all traces of the last commit. I guess we would prefer to have it logged somewhere. And it seems to leave the local checkouts and branches in an unstable status. Could you try "bzr revert"? I'm not sure "bzr update" works as expected after an uncommit.
-- Nicolas
On 28-10-2012 13:17, Nicolas Dufour wrote:
De : Johan Engelen<jbc.engelen@...2592...> We are currently on rev35 with gtk+ 2.24.10 according to your last commit message.
Exact.
The devlibs r35 readme.txt says gtkmm 2.24.2. Check the revision history *online*
http://bazaar.launchpad.net/~inkscape.dev/inkscape-devlibs/trunk/view/head:/... says gtkmm 2.22.0
(note that bazaar is... well......). There is no un-commit there. If un-committing does not show up in the history online, we should never do such a bzr (bizarre) action.
Well, yes, maybe I should have reverted the changes by committing a rev. 37. Uncommitting seems to remove all traces of the last commit. I guess we would prefer to have it logged somewhere. And it seems to leave the local checkouts and branches in an unstable status. Could you try "bzr revert"? I'm not sure "bzr update" works as expected after an uncommit.
Ok, completely deleted and then reverted my devlibs. Perhaps I had a local modification? Couldn't tell because the broken&slow Tortoisebzr/bzr-cmdline get bad data from the bzr server on trying to do a diff. Tortoise doesn't show overlay icons for this branch etc. Isn't bazaar just a wonderful world and major step forward from svn...? sigh...
-Johan
2012/10/28 Johan Engelen <jbc.engelen@...2592...>:
Ok, completely deleted and then reverted my devlibs. Perhaps I had a local modification? Couldn't tell because the broken&slow Tortoisebzr/bzr-cmdline get bad data from the bzr server on trying to do a diff. Tortoise doesn't show overlay icons for this branch etc. Isn't bazaar just a wonderful world and major step forward from svn...? sigh...
If you are making changes in the devlibs, you should use a normal checkout instead of a lightweight checkout. Otherwise almost every operation will be dog-slow.
Regards, Krzysztof
participants (3)
-
Johan Engelen -
Krzysztof Kosiński -
Nicolas Dufour