Bug #991

Windows build broken (CMake+svn_version.sh)

Added by Daniel Kaneider about 3 years ago. Updated over 2 years ago.

Status:ClosedStart date:13 Sep 2014
Priority:NormalDue date:
Assignee:Robin Mills% Done:


Target version:0.25



I just tried to compile Exiv2 using CMake and it didn't work on my Windows machine using VS2012. For some reason my Windows couldn't execute the svn_version.sh file...
On the other hand, that batch file generates a svn_version.h file which seems to be mandatory in the src/CMakeLists.txt file.

There may be different approaches to this problem:
- create and include a default "svn_version.h" file.
- replace the .sh hack with proper CMake commands. As I already suggested in #858 you can use FIND_PACKAGE(Subversion) and related commands
- don't require svn_version.h for Windows/CMake compilation


exiv2-cmake-svn-version.patch Magnifier (770 Bytes) Daniel Kaneider, 16 Sep 2014 14:09

Related issues

Related to Exiv2 - Bug #994: CMake: wrong build rule for svn_version.h Closed 09 Oct 2014

Associated revisions

Revision 3364
Added by Robin Mills about 3 years ago

Issue: #991 (Windows build broken (CMake+svn_version.sh). Thank You, Daniel for the patch.


#1 Updated by Robin Mills about 3 years ago

  • Status changed from New to Assigned
  • Assignee set to Robin Mills
  • Priority changed from Urgent to Normal


I've just run a CMake build with MSVC 2005 and that does not attempt to execute svn_version.sh

When I added the feature to include the svn revision in to the the build of Exiv2, I decided that this would not be supported by MSVC. So the code to generate the svn_version.h should not be executed for MSVC builds. So in CMakeLists.txt, you'll find:

  MESSAGE(STATUS         "generating ${CMAKE_CURRENT_SOURCE_DIR}/src/svn_version.h")
And in version.hpp:
// svn version has not been implemented yet for DevStudio
#if     defined(_MSC_VER)
#define SVN_VERSION 0
#include "svn_version.h" 
So I'm surprised this is causing you difficulty, as I believe I have engineered things correctly. Are you working on the trunk?

The reason to omit svn for MSVC is the dependency on locating svn.exe. The svn version number feature is intended for development purposes to differentiate different branches and builds. So for MSVC I report svn=0.

MSVC builds can't execute svn_version.sh because it's a bash script and intended for not MSVC environments (cygwin/mingw/linux/macosx).

I'll have to back-track and learn about FIND_PACKAGE(Subversion). As you know, I'm not strong with CMake and don't understand the FIND magic. However, it's important for me to master this as we're about to introduce more optional libraries to support the WebReady feature in v0.25.

You will be pleased to learn that we're developing a Jenkins build server for Exiv2. One of the challenges of Exiv2 is the size of the build/test matrix. Having a machine dedicated to building in response to commits will significantly improve our day-to-day build/test coverage. I purchased a Mac-Mini which runs the Virtual Machines running Windows and Linux in addition to the being a native Mac. I only acquired the machine 5 weeks ago and it's work in progress at the moment. http://exiv2.dyndns.org:8080

#2 Updated by Gilles Caulier about 3 years ago


Typically, you don't need to use a bash script to handle svn version ID.

This is how we do it with cmake about git version ID. There are 2 files :


This is the cmake script which run git binary with right option to get last commit ID.


This is the header file patched by previous cmake script to register git ID

In the past, digiKam has used svn, and we have handle svn commit ID by a similar way. But i cannot found relevant file in git history.

This can be certainly found in old digiKam archive. This kind of cmake script must be located in core/cmake/templates dir.

Note : it's always a good id to look in digiKam cmake code if a problem have not been already managed in the past. We have plenty of cmake code where you can find a good inspiration for Exiv2


#3 Updated by Robin Mills about 3 years ago

Thanks, Gilles

You are always very helpful. For sure the FIND_PROGRAM magic in CMake looks very useful. I appreciate that DigiKam and other projects are much more experienced in CMake. I have much to learn about CMake, as you know.

We build with ./configure and CMake. So the script svn_version.sh is invoked from either environment to update the file svn_version.h when the svn has been updated. I don't use svn_version.h at all in MSVC builds.

I'm not convinced that Exiv2 has a bug here. Let's wait for Daniel's comments. I believe he will be able to build successfully with CMake.


#4 Updated by Daniel Kaneider about 3 years ago

Hi Robin,

sorry that I didn't make it clear. CMake already failed in my case with the following error

CMake Error at src/CMakeLists.txt:191 (ADD_LIBRARY):
  Cannot find source file:


You were also right, that there is some special handling in the main CMakeLists file and in the .cpp regarding this file for msvc. However, the src/CmakeLists.txt always tries to include the svn_version.h file. I wonder how this could work in your case. Im using 3358, and my error is confirmed by the repository at http://dev.exiv2.org/projects/exiv2/repository/show/trunk/src where there is no svn_version.h file. Did you maybe use a non-clean source directory?

Anyway, with the small change, similar to the other places I fixed that place. Appending you find the patch. With that, I was able to compile to make an in-source build using VS 2012-x64. Sadly in-source, but thats another story you already know...


#5 Updated by Robin Mills about 3 years ago

  • Status changed from Assigned to Resolved
  • Target version set to 0.25

Thank You, Daniel. Yes - you are 100% correct. I've submitted your patch r3364. Thank You for working on this - and thanks for pushing to get to the bottom of this. I'm going to mark this "Resolved".

The MSVC build/test has been rather badly broken r3355 .. r3358. My submission r3359 should restore stability.

I've recruited a new build engineer Nehal Wani and hope he'll be able to spend more time on our CMake support next year. As you know, there are many things to deal with in a software project and limited resources and skills. So, while I regret that our CMake support is weak, I try my best to keep everything moving forward. When we have the Jenkins build server fully operational, perhaps with 2 build engineers on the project, we'll can improve our CMake support.

You are right to be suspicious that a dirty build tree could contain a version of svn_version.h from an earlier ./configure build. The Jenkins build does a "make distclean" on every build. At the moment, we haven't added the code for Jenkins to build using CMake - however we intend to do so.

Thank You once more for your contribution to Exiv2.

#6 Updated by Robin Mills over 2 years ago

  • % Done changed from 0 to 100

#7 Updated by Andreas Huggel over 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF

Redmine Appliance - Powered by TurnKey Linux