The CMake build system doesn't seem to be functional (link failure), so in the meantime I have an improvement to the Automake one.
I added a micro-library libinkversion.a that contains only the version string. It is built from a single source file which is generated based on configure.ac $(VERSION) and SVN information (if present), and is only replaced if it changes. This way the About box always has the SVN revision, with only a relink necessary (it would have been necessary anyway in most cases). The version string looks like: 0.46+devel r20503 custom The first part is the version from configure.ac; The second is the SVN revision; the third part "custom" is only present if there are any files modified in the src/ directory with respect to the SVN repository (checked with svn status -q).
Because of the way "svn info" works, the version will be wrong if you compile after commiting all changes (it won't have "custom" added even though it should). Currently I don't know how to handle this, but this shouldn't be a problem as this feature is mainly intended for users and testers. If anyone wants to fix this case, the code is in src/Makefile_insert
Regards, Krzysztof Kosiński
On Monday 12 January 2009 19:39:55 Krzysztof Kosiński wrote:
The CMake build system doesn't seem to be functional (link failure), so in the meantime I have an improvement to the Automake one.
If you have time I would love help figuring why the link failure happens.
I added a micro-library libinkversion.a that contains only the version string. It is built from a single source file which is generated based on configure.ac $(VERSION) and SVN information (if present), and is only replaced if it changes. This way the About box always has the SVN revision, with only a relink necessary (it would have been necessary anyway in most cases). The version string looks like: 0.46+devel r20503 custom The first part is the version from configure.ac; The second is the SVN revision; the third part "custom" is only present if there are any files modified in the src/ directory with respect to the SVN repository (checked with svn status -q).
Because of the way "svn info" works, the version will be wrong if you compile after commiting all changes (it won't have "custom" added even though it should). Currently I don't know how to handle this, but this shouldn't be a problem as this feature is mainly intended for users and testers. If anyone wants to fix this case, the code is in src/Makefile_insert
Regards, Krzysztof Kosiński
Ok the big issue here is this is not possible for most windows devs without downloading an additional version of svn i.e the command line tools as most windows devs use tortoiseSVN, and it does not contain the command line executable. I'm not against better version info, but doing this breaks the build for non-*nix users. So we need a way to do this on all platforms.dd
For the CMake build this changes what is basically an echo to file to something much more complex.
Joshua L. Blocher verbalshadow
Joshua L. Blocher wrote:
If you have time I would love help figuring why the link failure happens.
The current approach is to build a library for each source directory. However, since the dependencies between code in different directories are not clearly defined and there are some circular ones, this leads to simple changes breaking the build, because Unix linkers don't resolve backward references in static libraries, only in object files. What needs to be done: instead of building libraries, directly link the executable from all object files. Only build static libraries from things that are really libraries and are usable outside of Inkscape.
Ok the big issue here is this is not possible for most windows devs without downloading an additional version of svn i.e the command line tools as most windows devs use tortoiseSVN, and it does not contain the command line executable. I'm not against better version info, but doing this breaks the build for non-*nix users. So we need a way to do this on all platforms.dd
For the CMake build this changes what is basically an echo to file to something much more complex.
When it comes to the Windows build, I reused the existing rule that generated inkscape_version.h and just changed it to generate inkscape-version.cpp instead, so everything should still work. I couldn't test it though. For CMake, it is 100% implementable, because this is equivalent to the thing being done in UseGlibMarshal.cmake.
Regards, Krzysztof Kosiński
-----Original Message----- From: Krzysztof Kosiński [mailto:tweenk.pl@...400...] Sent: dinsdag 13 januari 2009 20:43 To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Version reporting improvement
When it comes to the Windows build, I reused the existing rule that generated inkscape_version.h and just changed it to generate inkscape-version.cpp instead, so everything should still work. I couldn't test it though. For CMake, it is 100% implementable, because this is equivalent to the thing being done in UseGlibMarshal.cmake.
Did you try the windows build?
No it doesn't work ofcourse, because inkscape-version.h is not generated any more.
J.B.C.Engelen wrote:
No it doesn't work ofcourse, because inkscape-version.h is not generated any more.
{facepalm}
inkscape-version.h is not generated anymore, it is a normal file - I forgot to add it to SVN... sorry. Try again with r20515. The generated file is inkscape-version.cpp
Regards, Krzysztof Kosiński
participants (3)
-
unknown＠example.com -
Joshua L. Blocher -
Krzysztof Kosiński