Bug #991

Windows build broken (

Added by Daniel Kaneider about 7 years ago. Updated over 6 years ago.

Target version:
Start date:
13 Sep 2014
Due date:
% Done:


Estimated time:



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 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 (770 Bytes) exiv2-cmake-svn-version.patch Daniel Kaneider, 16 Sep 2014 14:09

Related issues

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


Associated revisions

Revision 3364 (diff)
Added by Robin Mills about 7 years ago

Issue: #991 (Windows build broken ( Thank You, Daniel for the patch.



Updated by Robin Mills about 7 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

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 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.


Updated by Gilles Caulier about 7 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



Updated by Robin Mills about 7 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 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.



Updated by Daniel Kaneider about 7 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 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...



Updated by Robin Mills about 7 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.


Updated by Robin Mills over 6 years ago

  • % Done changed from 0 to 100

Updated by Andreas Huggel over 6 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF