When updating Inkscape to the most recent SVN revision I use:
| svn update
| 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.
From: Krzysztof Kosiński <tweenk.pl@gm...> - 2009-08-12 14:35:02
> 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.
View this message in context: http://www.nabble.com/removed-files-from-trunk-share-extensions-still-present-after-svn-update-make-make-install-tp24936490p24937924.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.