Re: [Inkscape-devel] [Inkscape-cvs] SF.net SVN: inkscape:[20521] inkscape/trunk/src
Whoa! This doesn't seem like a good idea. Why are you removing the version number from the menus file?
--Ted
On Wed, 2009-01-14 at 15:28 +0000, tweenk@...58... wrote:
Revision: 20521 http://inkscape.svn.sourceforge.net/inkscape/?rev=20521&view=rev Author: tweenk Date: 2009-01-14 15:28:20 +0000 (Wed, 14 Jan 2009)
Log Message:
Remove INKSCAPE_VERSION from menus-skeleton.h
Modified Paths:
inkscape/trunk/src/menus-skeleton.hRemoved Paths:
inkscape/trunk/src/inkscape_version.h.mingwThis was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Inkscape-cvs mailing list Inkscape-cvs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-cvs
Hi Krzystof,
Did you see Ted's email? I have the same concern and am going to revert your change.
Johan
-----Original Message----- From: Ted Gould [mailto:ted@...11...] Sent: woensdag 14 januari 2009 19:27 To: tweenk@...58... Cc: Inkscape Devel List Subject: Re: [Inkscape-devel] [Inkscape-cvs] SF.net SVN: inkscape:[20521]inkscape/trunk/src
Whoa! This doesn't seem like a good idea. Why are you removing the version number from the menus file?
--TedOn Wed, 2009-01-14 at 15:28 +0000, tweenk@...58... wrote:
Revision: 20521
http://inkscape.svn.sourceforge.net/inkscape/?rev=20521&view=rev
Author: tweenk Date: 2009-01-14 15:28:20 +0000 (Wed, 14 Jan 2009)
Log Message:
Remove INKSCAPE_VERSION from menus-skeleton.h
Modified Paths:
inkscape/trunk/src/menus-skeleton.hRemoved Paths:
inkscape/trunk/src/inkscape_version.h.mingwThis was sent by the SourceForge.net collaborative
development platform, the world's largest Open Source development site.
This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Inkscape-cvs mailing list Inkscape-cvs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-cvs
J.B.C.Engelen wrote:
Hi Krzystof,
Did you see Ted's email? I have the same concern and am going to revert your change.
Johan
Sorry for the lag. After my modification inkscape_version.h wasn't generated at all, and the build failed because it was used in menus-skeleton.h.
I want to get rid of inkscape_version.h in favor of a mini-library that contains the version string, obtainable using a simple function This wouldn't require a sizable portion of Inkscape to be recompiled whenever the version changes - only a recompile of one trivial file and a relink would be needed. We could then have the SVN revision number in every binary. This would help out with testing nightly builds, because we sometimes couldn't reproduce a bug that wasn't there because it was fixed in the next SVN revision.
The mini-library design has a drawback - namely that the version cannot be incorporated into static strings. However, this only affected the preferences-skeleton.h and men-skeleton.h. Those files don't need a version, because the XML fragment is not a file - it is internal data, so it just doesn't make any sense to have the version number there. Probably I should have commented on this more in the SVN commit log.
Regards, Krzysztof Kosiński
On Mon, 2009-02-09 at 10:37 -0800, Krzysztof Kosiński wrote:
J.B.C.Engelen wrote:
Did you see Ted's email? I have the same concern and am going to revert your change.
I want to get rid of inkscape_version.h in favor of a mini-library that contains the version string, obtainable using a simple function This wouldn't require a sizable portion of Inkscape to be recompiled whenever the version changes - only a recompile of one trivial file and a relink would be needed. We could then have the SVN revision number in every binary. This would help out with testing nightly builds, because we sometimes couldn't reproduce a bug that wasn't there because it was fixed in the next SVN revision.
The mini-library design has a drawback - namely that the version cannot be incorporated into static strings. However, this only affected the preferences-skeleton.h and men-skeleton.h. Those files don't need a version, because the XML fragment is not a file - it is internal data, so it just doesn't make any sense to have the version number there. Probably I should have commented on this more in the SVN commit log.
Well, simply put those aren't only internal data, because they get written out to the filesystem. Basically that's the template data that gets written. So we need the version number in them in-case we need to make incompatible changes for some reason.
--Ted
participants (3)
-
unknown＠example.com -
Krzysztof Kosiński -
Ted Gould