removed files from trunk/share/extensions still present after svn update/make/make install
When updating Inkscape to the most recent SVN revision I use:
| svn update | make | make install
and then build the application bundle for macosx.
When files are removed from trunk/share, like recently some extensions (in rev. 22049), those files still exist in 'Build/share/inkscape/extensions' and are not removed when I do 'make' and 'make install' after 'svn update'.
Do I have to manually clean the Build/share directories when updating from SVN, or is there a make target that specifically does this instead of the overall 'make clean'?
The issue has come up before with packages for win32 which included long gone extension files.
On a side note - the build date (shown in the about screen) also doesn't update with every make/install/package cycle - though the revision number is always correct.
tia, ~suv
~suv-2 wrote:
Do I have to manually clean the Build/share directories when updating from SVN, or is there a make target that specifically does this instead of the overall 'make clean'?
Yes. Automake doesn't handle disappearing files well (or in fact at all). By the way, that's one of the reasons there is no way to partially rebuild a Debian package after you make some changes - you either build it from scratch or not at all.
On a side note - the build date (shown in the about screen) also doesn't update with every make/install/package cycle - though the revision number is always correct.
That's because currently it's only updated when aboutbox.cpp is rebuilt. You can say 'touch src/ui/dialog/aboutbox.cpp' to update it. The correct solution involves dynamically creating an compiling an additional .cpp file that contains the current date on every 'make'. Bonus points for translating it at runtime. I'll look into this some time after GSoC.
Regards, Krzysztof
participants (2)
-
Krzysztof Kosiński -
~suv