Exiv2

Daniel

I have news for you. Gilles and Islam (a new GSoC 2015 student) are going to accept responsibility for CMake/MSVC. The last few weeks have been really hard going for me and I put CMake to the bottom of the stack to focus on other matters. Friends have arrived from California and we're going off for a break until April 10. However we have more engineers coming to work on Exiv2 and something will be done about this.

Islam isn't going to join us after all. He's going to do a Rails project. I have agreed to do the webp/webm project #1048

I do not intend to anything about CMake/MSVC It states clearly in the README-CMAKE:

• CMake scripts are "work in progress".
  Use them only if you're prepared to fix them.
  See TODO-CMAKE for known pending tasks.

I am not even willing to submit a patch. Somebody else must take ownership of CMake/MSVC because I am overloaded.

Under no circumstances will I do any further work on CMake/MSVC. I am overloaded. I appreciate that Daniel has provided some assistance and encouragement. However, I can do nothing more about this matter.

I can't commit to maintain this part (as I have no windows PC outside work). However, I could fix a few things, see this forum thread.
My next step for the windows build is to check why we add issues with cmake's FindZlib.

Currently, our build workflow (that successfully works) is the following:
- build zlib and expat separately
- pass the path to these outputs to exiv2 via the cmake options
- build successfully (both inside MSVC's IDE and by calling devenv).

Thank, Emmanuel. I've understood that you're not committing to dealing Exiv2/CMake/Visual Studio. However, it's easier to understand different activity by you and Daniel and I when we discuss things in one location.

I have problems with the the last 2 revisions: 3948 and 3958:

1. Rev 3948:
ZLIB_LIBRARIES contains already the extension when using CMake gui. It should not be added by CMake itself. So this changeset breaks my compilations on Windows.
Adding unconditional the extension will also break later when the zlib detection is revised. Please revert this revision.

1. define EXV_UNICODE_PATH
   #endif
   with the consequence that all programs which are using exiv2 as library have to add this define in its own code (when the want to use the UNICODE code) which is ugly and can result in mismatches between library and calling program. And so there is no way for the calling program to test if this feature is available or not.
   If you want to make it configurable then the EXV_UNICODE_PATH define should be remain in config.h, maybe using some #cmakedefine variant, but not in the build system where it is unavailable for external programs.

(Furthermore adding EXV_UNICODE_PATH only to the build environment, it is then missing in the supplied project files.)

I don't know if there are version differences in CMake. But it assume this behaviour is the same in all recent versions. (Otherwise there would be more complains after last release, which is using the old version)

As far as I tested, all FIND_PACKAGE routines return the full name with extension of the libraries and the ZLIB_LIBRARIES (as other other libraries) is by default a list item:
(from FindZLIB.cmake)
ZLIB_LIBRARIES - List of libraries when using zlib.
Just adding the extension will only concat 2 strings, but not add the extension to each list item. So this approach does not work in this way.
So I assume Emmanuel is only supply the filename without extension to CMake. He should supply the full filename with extension.

Groan. I'll look at this later. I really dislike CMake. It's full of black magic such as FIND_MAGIC. I don't understand cmake nor how it works. It's just trouble with Visual Studio. Lots of folks have told me that it's really great - however none of its supporters have stepped forward to help by taking this crap off my back.

Well, we supply the exact name (with extension) of the target zlib. I checked the FindZLib script but couldn't detect anything that helps. I have still to check between cmake 3.3.1 and previous cmake versions, because we didn't have this issue with an older version of cmake (so this may be due to a discrepancy between 3.3 and older instead of a discrepancy between cmake and cmake-gui). Checking the generated sln file does indeed show that the generated linker command is without extension on all our test machines (win8, Visual Studio 2013, cmake 3.3.1). If I find a better solution I will post it here.

For the unicode flag we have the exact opposite problem. It doesn't get defined automatically from the build environment, and we used to manually patch the sources before building. Although that may sound a bit controversial, I do anyway prefer to explicitly set definitions and compile-time options. This makes easier to check what really happens and allows easier compatibility (consistency) with third party code that may not embed the same magic-fu for guessing environment settings (and we have scripting when command lines become too long to type once in a while).

It seems that in cmake 3.1.0 there was a change in FindZLib that has to deal with the library extensions. I don't completely understand the cmake language, but it could explain the different behaviour that I observed (we use cmake 3.3.1, so posterior to this commit). If it's the root cause, then we can probably add a conditional statement based on cmake version.

Thanks for digging into the changes in versions of FindZLIB.cmake.

I'll have a look into that later today. I'm not very enthusiastic to use the CMake version to decide about the .lib because I believe scripts like FindZLIB.cmake are not always found in the default cmake location. For sure, curl, libssh, podofo have variants of that file in their source tree. This is complex magic (complex magic = more that one recipe for the magic).

CMake has commands for string regex matching. Maybe all I need to do is to something like the following pseudo code:

ZLIB_OPTIM = ${ZLIB_LIBRARIES}
ZLIB_DEBUG = ${ZLIB_LIBRARIES}d
if ( not ${ZLIB_OPTIM}( REGEX MATCH "lib$") )
   ZLIB_OPTIM = $ {ZLIB_OPTIM}.lib
endif()
if ( not ${ZLIB_DEBUG}( REGEX MATCH "lib$") )
   ZLIB_DEBUG = $ {ZLIB_DEBUG}.lib
endif()
TARGET_LINK_LIBRARIES( exiv2lib optimized ${ZLIB_OPTIM} debug ${ZLIB_DEBUG} )

The FindZLib script from Cmake seems to be shipped with standard installs. I still have some work on Linux to do today and tomorrow morning, but I'll try to reboot on windows and compare the behaviour between different cmake versions tomorrow afternoon (continental Europe time, that is).

Also, I though a bit about this unicode flag (besides the fact that I prefer explicit flags instead of magic). We do a lot of work from the git bash interpreter, but the final build of the lib can be done directly in windows's command tool. This could explain why the environment doesn't get detected as genuine windows in our setup.

Oh, and maybe you can't make everyone happy at the same time: https://xkcd.com/1172/ ;)

No question, we can't please everybody all of the time. However we can aim to make everybody happy!

I'm in England, so I'm one hour behind you.

I investigated the changes between FindZLIB.cmake on 3.0.0 and 3.1.0. I didn't see anything odd or windows specific. I have Visual Studio 2013 and 2015 installed and working properly now and I'll run some builds on Windows/CMake. I'll make you and T happy on Thursday or Friday. You'll see.

1. The arguments you pass to the tools
2. Your environment strings

I believe the Git/bash shell is about the same as Cygwin which is the windows shell on our buildServer. Our buildServer is Jenkins and runs on a Mac. The server has 3 "nodes": MacOS-X, Linux and Windows (Linux and Windows are VMs running on the Mac). Jenkins knows the IP addresses of the nodes and uses ssh to run scripts on the nodes. The Windows node is a Cygwin server running bash. The build script is jenkins_build.sh

To build with MSVC, jenkins_build.sh invokes CMD.exe to run jenkins_build.bat which runs devenv.exe.
To build on MinGW, jenkins_build.sh invokes the MinGW bash interpreter to perform the build.

The script buildJenkins.sh is the most complex bash script I've ever engineered. (complex != complicated. complex = invokes other magic). It's not intended to be magic. It's how I made it work reliably.

I found a more correct way of designating a custom zlib folder to the cmake build script: we were using the option -DZLIB_LIBRARY=some\path\to\zlib (which gave us troubles) to set the path to the library and the name of the file to use, but using instead the option -DZLIB_ROOT=path\to\custom\zlib\folder yields the correct behaviour for the release build.
By correct, I mean that the generated Visual Studio project file tries to link with zlib.lib in release. In debug, it tries to link with zlib.libd (we have the release and debug libs in the same folder and use the cmake debug postfix set to d).

I'm still investigating how to designate a particular library file in this root folder.

Thanks for your time!

Hi Robin!

I have good news for you! I think I finally found the issue that I was struggling with.

I checked the output of the FindZLib module once again, since T Modes found that it worked on his side. It is actually also working for us, except that... we build the release then the debug versions successively in the same script. As a consequence, I could only have a look at the Debug build output, and I'm sorry but there is a small bug that leaped into exiv2's debug build linker command.

If you go to src/CmakeLists.txt, line 272, you can read:

TARGET_LINK_LIBRARIES( exiv2lib optimized ${ZLIB_LIBRARIES} debug ${ZLIB_LIBRARIES}d )

• in Release builds the linker will search for @${ZLIB_LIBRARIES} = zlib.lib$ => it works nicely
• in Debug builds the linker will search for @${ZLIB_LIBRARIES}d = zlib.libd$ => link failure.

Sorry, I tried to Preview and hit the wrong button...

• changing the linker line to TARGET_LINK_LIBRARIES( exiv2lib ${ZLIB_LIBRARIES}) since it works, and users who want a debug build need to set it manually to zlibd.lib (I couldn't get cmake to use it instead, although we use the option -DCMAKE_DEBUG_BUILD_POSTFIX=d)
• stripping the lib extension from the ${ZLIB_LIBRARIES} before adding the d.

This could be (should be?) conditional to the fact that the user has provided a direct path to zlib.

Sorry, I'm a bit confusing and thinking out loud, but I hope this helps you!

Thanks,

Emmanuel

Thanks for letting me know about your discoveries. I hope the user does NOT have to specify stuff like DCMAKE_DEBUG_BUILD_POSTFIX. To the user, it should "just work". There is pattern match/replace stuff in CMake very much like sed:

$ echo '/how/now/brown/cow/zlib.lib' | sed -E -e 's/(.*)(\.lib)/\1d\2/'
/how/now/brown/cow/zlibd.lib
$ echo '/how/now/brown/cow/zstaticlib.lib' | sed -E -e 's/(.*)(\.lib)/\1d\2/'
/how/now/brown/cow/zstaticlibd.lib
$ 

This morning I saw the following very helpful and totally meaningless message from CMake:

-- Could NOT find EXPAT (missing:  EXPAT_LIBRARY) (found version "2.1.0")

I like Visual Studio. There's a simple linear relationship between foo.vcproj files, the GUI, and the generated command-lines. I have never worked inside .vcxproj files and assume they are much the same. Unlike Xcode project.pbxproj file, it's easy (and safe) to edit Visual Studio project files.

With CMake, you have a weird declarative language that imposes a build abstraction from which the .vcproj files are generated. The FindFOO.cmake files are volatile/random magic at best. The projects which are generated by CMake don't feel "Native" to me. They have weirdo build targets and config names. And the user must generate different project files for every version of Visual Studio using generator names which are very difficult to type or remember. I don't believe you can create a single project from which the user can choose architecture (32/64) or library types (static/shared). And of course it keeps running CMake when it builds - so if you "tweak" a project setting in the GUI, CMake will "untweak" it for you. All of this adds up to horrible.

Anyway, thanks to you, we're making progress. Several users have complained about Exiv2 support for CMake/Visual Studio. They criticise and tell me that CMake is easy and great. You're the first to provide constructive help. Thank You very much.

I'm a bit surprised by your EXPAT errors. Currently, I can successfully build exiv2 on Windows with custom zlib + expat using the following script (omitting non-relevant parts):

cmake ^
-G "Visual Studio 12 2013 Win64" ^
-DCMAKE_BUILD_TYPE=Release ^
-DCMAKE_INSTALL_PREFIX=%tmp_install_path% ^
-DZLIB_INCLUDE_DIR=%some_include_path%\zlib ^
-DZLIB_LIBRARY=%some_lib_path%\zlib.lib ^
-DEXPAT_INCLUDE_DIR=%some_include_path%\expat ^
-DEXPAT_LIBRARY=%some_lib_path%\libexpat.lib ^
%build_path%

devenv %build_path%\build\exiv2.sln /Build "Release|x64" /Project INSTALL

I guess that parts of the errors on our side come from the fact that we specify everything (build type + library paths and names) and that we should maybe delegate this to the call to devenv instead. This should hold for the CMAKE_DEBUG_POSTFIX option too. I still think it's ok to specify it, it's actually useful for the build result and I don't think that it has any impact on the input library names.
We should have something working and robust for 0.26, the goal is not too far anymore :-)

As an off topic, on the other hand I like Xcode and its file format (most of its core is actually legacy from the NextStep dev tools). Not a big fan of vcxproj formats, but it's probably because I'm not used to windows build environment. I like studying these formats by looking at the changes in my source control system (git), it's a nice way to see the impact of clicking on buttons.

I also came to like cmake as a replacement of hand crafted Makefiles + scripting magic to explore folders, sub-folders, add targets... It's a nice tool to use on the command line, ie, a nice tool for *nix and mac os. What I really dislike about cmake is its lack of documentation (besides the usual getting started stuff). I'm not even sure that buying the book is a good idea, since it's based on older versions of the tool.

Thanks very much. I've almost got it to build with your command-line. That's great. I have to get on with the house building this morning, so I'll have a more careful look later today.

I have a feeling that the result of our cooperation is going to be a rewrite of README-CMAKE for Visual Studio and perhaps a few little code changes. What a fantastic improvement that will be.

I have the CMake book. I bought it to work on this for Exiv2. The book is a reprint of the man pages on the Kitware web-site. I see they are selling them cheaply today, so I expect they have a new edition coming soon. I don't know if I would recommend the book or not. I can send you my copy (I never look at it) in the mail and you can decide. Email me your address: robin@clanmills.com

The Xcode xcconfig feature is really great. Sadly, if you edit almost anything in project.pbxproj, Xcode refuses to open the file. And that file is full of GUIDS.

Autotools is a black art. Sure it works, although nobody knows how or why. The next time you are on a plane (be it an Airbus or a Boeing), just remember that the flight control software (and the air-traffic control software) was almost certainly build using this stuff. Pray for a safe landing.

• users who just build the library using regular, system-wide libraries, in which case the cmake should already work kind of automagically
• users like our company who customize a lot of things. In this case, I don't think that the cmake script should over-guess the configuration, as we are supposed to know what we are doing. It should merely try to respect the parameters that we give as inputs (which is already almost done, except for this d suffix in the debug configuration zlib).

I will have a little spare time next week(s) to finalize all this and update the README-CMAKE.

Thanks for the offer! But I'll wait for a next version of the book (if any), and I'm already disliking the man pages (I find the policies description confusing at best).
And I got my first degree from an aerospace engineering school (I came to software engineering later in my career), I do already pray for a lot of things when I fly ;-)

Aerospace, eh! I did Civil Engineering and worked as a Structural Engineer for a couple of years after University. I think there's a lot in common between Structures and Software. I retired last year after 41 years of hard work. The last 14 years were in Silicon Valley (Adobe, Apple, Google). I never miss work.

When I worked on the PostScript Interpreter, we'd often put pixels on the wrong place on the page. One pixel on a A4 page at 600dpi is about the same resolution as a city like Moscow relative to planet Earth. We are in more danger from our software engineers than the enemy. I have my doubts about the reliability and accuracy of a Trident Missile. Let's hope the politicians are never stupid enough to use the damn things.

It would be totally awesome for you to do a little work on README-CMAKE. Thanks very much.

Have a nice weekend. Very nice weather forecast for England this weekend. I hope the weather's good for you.

This morning I saw the following very helpful and totally meaningless message from CMake:

-- Could NOT find EXPAT (missing: EXPAT_LIBRARY) (found version "2.1.0")

WTF?

Simple ;-): It has found the expat header, they are from version 2.1.0, but the expat library was not found. As a result expat is marked as "not found", because without the lib you can't link.

I don't believe you can create a single project from which the user can choose architecture (32/64) or library types (static/shared).

Yes, you can't choose architecture, but different library types are possible. You need only one add_library call for each type. Something like

if( EXIV2_ENABLE_STATIC )
ADD_LIBRARY( exiv2lib_static STATIC ${LIBEXIV2_SRC} ${LIBEXIV2_HDR} )
endif()
if(EXIV2_ENABLE_SHARED)
ADD_LIBRARY( exiv2lib SHARED ${LIBEXIV2_SRC} ${LIBEXIV2_HDR} )
endif()
(you need only the check before that at least one option is enabled.)

At Hugin we are using a modified FindZlib.cmake module (see http://hg.code.sf.net/p/hugin/hugin/file/8f75794f051f/CMakeModules/FindZLIB.cmake )
This handles also the debug variants. Maybe this can give you some ideas.

@Emmanuel

cmake ^
-G "Visual Studio 12 2013 Win64" ^
-DCMAKE_BUILD_TYPE=Release ^

<snip>

I think you don't need to specify CMAKE_BUILD_TYPE. The project files contain always all 4 variants. You select the variant in Visual Studio or on the command line (as you do with "devenv build_path\build\exiv2.sln /Build "Release|x64" /Project INSTALL"). So you leave the parameter on the cmake command line.

Thank you, T. This is very helpful. Cooperation is 100 times more effective than criticism. We're really moving now on this issue. Thanks for helping.

And thanks for explaining the message: Could NOT find EXPAT (missing: EXPAT_LIBRARY) (found version "2.1.0") That makes good sense when you explain it.

I know that CMake can build shared or static libraries. However they are CMake options. Once you're in Visual Studio, can you say "build shared", "build static". I like the way things are in the existing msvc2005 projects. You open the solution and can select 32/64, shared/static, debug/release. So it's a one stop shop with the 8 common builds available. Is it possible to generate this with CMake?

You open the solution and can select 32/64, shared/static, debug/release. So it's a one stop shop with the 8 common builds available. Is it possible to generate this with CMake?

32/64 bit: not possible in one solution
shared/static: I think this is not possible with a simple switch in the MSVC project file. Workaround is to add 2 library variants (2 calls to add_library, but maybe more work intensive if there are further sub-libraries.) But in this case always 2 variants are built (or the variants you build with CMake options). This variant is used by zlib's CMake system (you get an zlib and a zlibstatic target).
debug/release: works out of the box with CMake. The generated MSVC project files contains (always?) 4 solutions sets: Debug/Release/MinSizeRel/RelWithDebInfo

Maybe I can help you with the FindFOO magic.
As far as I understood there are mainly 4 parts:
1. Look for path of header files, e.g.
FIND_PATH(FOO_INCLUDE_DIR
NAME foo.h
PATHS search paths...
)

2. Look for the library
FIND_LIBRARY(FOO_LIBRARIES
NAMES foo libfoo
PATHS search paths ...
)

(in Hugin we are using a own written variant for better handling of debug libs:
include(FindLibraryWithDebug)
find_library_with_debug(FOO_LIBRARIES
WIN32_DEBUG_POSTFIX d
NAMES foo libfoo
PATHS search paths
)

3. Check if all was found (this handles also FOO_FOUND variable) and handle standard arguments of find_package call (e.g. required, quiet switches)
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(FOO DEFAULT_MSG FOO_INCLUDE_DIR FOO_LIBRARIES)

4. Often the variables are marked as advanced, so there are not shown by default in the GUI (except you tick the advanced box), when running from the command line this has no consequences.

MARK_AS_ADVANCED(FOO_INCLUDE_DIR FOO_LIBRARIES )

(Adding version checking depends on the library, because there are different ways how libraries define their version numbering.)

Thank You once more. Very helpful. My concerns about CMake are totally restricted to Visual Studio. CMake works very well on Cygwin/MinGW/Mac/Linux with GCC and Clang. And it's clear how it works on those platforms. No autotools magic required. We had students working with us on Google Summer of Code in 2013 and they all liked CMake much more than the autotools. I took care of Visual Studio on those projects, so they didn't offer an opinion about Visual Studio.

2. Look for the library
FIND_LIBRARY(FOO_LIBRARIES
NAMES foo libfoo
PATHS search paths ...
)

What are the search paths on Windows?

What are the search paths on Windows?

On Windows there is not a single place where the libs are stored. So we have to take some reasonable assumptions: assume the user store all libraries in the same directory level side by side.
So in the main CMakeLists.txt we store the main path:

# For Win32 builds, assume that all of the libraries are located
# one directory above the current CMakeLists directory
IF(WIN32)
  STRING(REGEX REPLACE "(.*)/[^/]+$" "\\1" work "${CMAKE_SOURCE_DIR}")
  # create the cache entry, editable by the user
  SET(SOURCE_BASE_DIR ${work} CACHE FILEPATH "parent dir of hugin source root")
ENDIF(WIN32)

and in FindFOO.cmake you could use e.g.
${SOURCE_BASE_DIR}/foo/include
${SOURCE_BASE_DIR}/foo/lib
as search path for the header and lib.

Well this seems to be a big step forward. I'm getting errors because the linker cannot find expat. I'll figure this out on Sunday.

Gentlemen: I've promoted you both to be an 'Administrator' of the Forum. This grants you permission to edit posts. So, T, may I ask you to fix the formatting in #37 - or (better) - delete #38 and update #37 to include the information in #38.

I do not have an issue with zlibd.lib and zlib1.lib. However I have to resolve the expat puzzle first. Here are the link commands for exiv2.exe.

Debug:

/OUT:"C:\cygwin64\home\rmills\gnu\exiv2\trunk\bin\x64\Dynamic\Debug\exiv2.exe" /MANIFEST /NXCOMPAT /PDB:"C:/cygwin64/home/rmills/gnu/exiv2/trunk/bin/x64/Dynamic/Debug/exiv2.pdb" /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "comdlg32.lib" "advapi32.lib" "..\bin\x64\Dynamic\Debug\exiv2.lib" "..\bin\x64\Dynamic\Debug\xmp.lib" "..\..\expat-2.1.0\Debug\expat.lib" "..\..\zlib-1.2.7\Debug\zlibd.lib" /IMPLIB:"C:/cygwin64/home/rmills/gnu/exiv2/trunk/bin/x64/Dynamic/Debug/exiv2.lib" /DEBUG /MACHINE:X64 /INCREMENTAL /PGD:"C:\cygwin64\home\rmills\gnu\exiv2\trunk\bin\x64\Dynamic\Debug\exiv2.pgd" /SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"exiv2.dir\Debug\exiv2.exe.intermediate.manifest" /ERRORREPORT:PROMPT /NOLOGO /LIBPATH:"C:/cygwin64/home/rmills/gnu/exiv2/trunk/bin/x64/Dynamic/Debug" /LIBPATH:"C:/cygwin64/home/rmills/gnu/exiv2/trunk/bin/x64/Dynamic/Debug/Debug" /TLBID:1 

/OUT:"C:\cygwin64\home\rmills\gnu\exiv2\trunk\bin\x64\Dynamic\Release\exiv2.exe" /MANIFEST /NXCOMPAT /PDB:"C:/cygwin64/home/rmills/gnu/exiv2/trunk/bin/x64/Dynamic/Release/exiv2.pdb" /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "comdlg32.lib" "advapi32.lib" "..\bin\x64\Dynamic\Release\exiv2.lib" "..\bin\x64\Dynamic\Release\xmp.lib" "..\..\expat-2.1.0\Release\expat.lib" "..\..\zlib-1.2.7\Release\zlib.lib" /IMPLIB:"C:/cygwin64/home/rmills/gnu/exiv2/trunk/bin/x64/Dynamic/Release/exiv2.lib" /MACHINE:X64 /INCREMENTAL:NO /PGD:"C:\cygwin64\home\rmills\gnu\exiv2\trunk\bin\x64\Dynamic\Release\exiv2.pgd" /SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"exiv2.dir\Release\exiv2.exe.intermediate.manifest" /ERRORREPORT:PROMPT /NOLOGO /LIBPATH:"C:/cygwin64/home/rmills/gnu/exiv2/trunk/bin/x64/Dynamic/Release" /LIBPATH:"C:/cygwin64/home/rmills/gnu/exiv2/trunk/bin/x64/Dynamic/Release/Release" /TLBID:1 

I extended the contrib/msvc build scripts. Now I was able to compile exiv2 with complete webready support (including ssl, ssh, curl). Maintaining old VS project files along with CMake is still cumbersome. Therefore I merged the exv_msvc content with config.h.cmake (used for *nix cmake)

@Robin: is there some jenkins build (*nix or msvc) which is already using CMake? It would be very helpful.

After playing around a little bit with github I activated some CI builds they offer via Travis CI free of charge (for open sourced, github project).
Builds are currently successful for Linux and OSX, both for gcc and clang. This both includes standard build and with webready. Since the update of the github repo is done through svn2github, the CI is rather semi-automatic. But, it fully uses CMake for executing the builds (.travis.yml).

Nice. Here's the link https://travis-ci.org/danielkaneider/exiv2_

Btw, if you add danielkaneider@b7c8b350-86e7-0310-a4b4-de8f6a8f16a3 to you GitHub emails you'll easily recognize your contributions to exiv2_.

I'm rather puzzled by this Travis business. I thought the focus of this topic is to build Exiv2/MSVC/CMake. At the moment, I'm been 100% unable to get the build.cmd and env.cmd to work. And now we're shifted focus to a continuous build server for Linux and Mac. The Jenkins server is already performing this task well.

In what way does Travis help with the topic: "CMake toolchain for windows"?

Robin, I get it. Nobody seems to care about CMake. Why else does Jenkins still use the make projects?
This issue is not just about CMake on windows, but also for Unix/Mac. Some of the features (mainly testing) are still not at the point they should be. So, Travis adds some CI builds to check if some builds work on Unix/Mac. You are free to create an additional build config for CMake in Jenkins. Just have a look at the .travis.yml to see which CMake commands I currently execute.

And regarding CMake on Windows, maybe it's time that you send me some log/build output. I cannot do more than offering my help. At least on my machine I can confirm that it does work (VS2013, Cmake 2.8 and CMake 3.3 for Win64) :-)

Still trouble with VS 2012, 2013 and 2015. Very frustrating and tedious.

I'm beginning to wonder if it's possible to install all those VS Editions on the same machine. Between the laptop and the buildserver, I believe I have a working copy of every version of Visual Studio. However I can't get them all to work on a single machine.

84 rmills@rmillsmm-w7:/c/gnu/exiv2/build $ grep -e ^generator -e ^version -e ^bits -e FAILED rebuild.txt
generator = Visual Studio 11 2012 Win64
generator = Visual Studio 10 2010 Win64
bits=64
version=10.00 (2010)
generator = Visual Studio 14 2015 Win64
generator = Visual Studio 12 2013 Win64
Done Building Project "C:\gnu\exiv2\build\temp\exiv2\src\exiv2lib.vcxproj" (default targets) -- FAILED.
Done Building Project "C:\gnu\exiv2\build\temp\exiv2\samples\addmoddel.vcxproj" (default targets) -- FAILED.
Done Building Project "C:\gnu\exiv2\build\temp\exiv2\ALL_BUILD.vcxproj" (default targets) -- FAILED.
Build FAILED.
generator = Visual Studio 9 2008 Win64
bits=64
version=9.00 (2008)
generator = Visual Studio 8 2005 Win64
bits=64
version=8.00 (2005)
generator = Visual Studio 11 2012
generator = Visual Studio 10 2010
bits=32
version=10.00 (2010)
generator = Visual Studio 14 2015
generator = Visual Studio 12 2013
Done Building Project "C:\gnu\exiv2\build\temp\exiv2\src\exiv2lib.vcxproj" (default targets) -- FAILED.
Done Building Project "C:\gnu\exiv2\build\temp\exiv2\samples\addmoddel.vcxproj" (default targets) -- FAILED.
Done Building Project "C:\gnu\exiv2\build\temp\exiv2\ALL_BUILD.vcxproj" (default targets) -- FAILED.
Build FAILED.
generator = Visual Studio 9 2008
bits=32
version=9.00 (2008)
generator = Visual Studio 8 2005
bits=32
version=8.00 (2005)
85 rmills@rmillsmm-w7:/c/gnu/exiv2/build $

I've discovered that stdint.h on VS 2012 and 2013 cause many compiler errors. Fixed that. And I've enhanced cmakeBuild to build into directories such as dist/2008/x64/dll/Release/. This will make it easy to have a "daily/weekly/monthly" builds archived for users. r4060

Still have trouble with VS2010 on the laptop. Here's how I test that the compiler is working.

C:\temp>type foo.cpp
#include <stdio.h>
int main(int,const char**)
{
        return printf("%d sizeof(void*) = %d",_MSC_VER,sizeof(void*));
}

C:\temp>

C:\temp>for %a in (64 32) do for %v in (2005 2008 2010 2012 2013 2015) do cmd /C "vcvars %v %a>NUL && nmake -a foo.exe >
/NUL 2>/NUL && foo.exe" 

C:\temp>for %v in (2005 2008 2010 2012 2013 2015) do cmd /C "vcvars %v 64>NUL && nmake -a foo.exe >/NUL 2>/NUL && foo.ex
e" 

C:\temp>cmd /C "vcvars 2005 64>NUL && nmake -a foo.exe >/NUL 2>/NUL && foo.exe" 
1400 sizeof(void*) = 8
C:\temp>cmd /C "vcvars 2008 64>NUL && nmake -a foo.exe >/NUL 2>/NUL && foo.exe" 
1500 sizeof(void*) = 8
C:\temp>cmd /C "vcvars 2010 64>NUL && nmake -a foo.exe >/NUL 2>/NUL && foo.exe" 
1600 sizeof(void*) = 8
C:\temp>cmd /C "vcvars 2012 64>NUL && nmake -a foo.exe >/NUL 2>/NUL && foo.exe" 
1700 sizeof(void*) = 8
C:\temp>cmd /C "vcvars 2013 64>NUL && nmake -a foo.exe >/NUL 2>/NUL && foo.exe" 
1800 sizeof(void*) = 8
C:\temp>cmd /C "vcvars 2015 64>NUL && nmake -a foo.exe >/NUL 2>/NUL && foo.exe" 
1900 sizeof(void*) = 8
C:\temp>for %v in (2005 2008 2010 2012 2013 2015) do cmd /C "vcvars %v 32>NUL && nmake -a foo.exe >/NUL 2>/NUL && foo.ex
e" 

C:\temp>cmd /C "vcvars 2005 32>NUL && nmake -a foo.exe >/NUL 2>/NUL && foo.exe" 
1400 sizeof(void*) = 4
C:\temp>cmd /C "vcvars 2008 32>NUL && nmake -a foo.exe >/NUL 2>/NUL && foo.exe" 
1500 sizeof(void*) = 4
C:\temp>cmd /C "vcvars 2010 32>NUL && nmake -a foo.exe >/NUL 2>/NUL && foo.exe" 
1600 sizeof(void*) = 4
C:\temp>cmd /C "vcvars 2012 32>NUL && nmake -a foo.exe >/NUL 2>/NUL && foo.exe" 
1700 sizeof(void*) = 4
C:\temp>cmd /C "vcvars 2013 32>NUL && nmake -a foo.exe >/NUL 2>/NUL && foo.exe" 
1800 sizeof(void*) = 4
C:\temp>cmd /C "vcvars 2015 32>NUL && nmake -a foo.exe >/NUL 2>/NUL && foo.exe" 
1900 sizeof(void*) = 4

r4072 Builds 32/64 on Visual Studio 2005/8/10/12/15 with/without --webready.
r4070 Added pre-built openssl-1.0.1p for vs2005
Everything builds including curl and libssh.

Daniel has reported a libssh/VS2015 build issue: https://red.libssh.org/issues/205 I have updated that issue with my work-around.

I have reported a libssh/VS2005 (&2008) build issue and work-around: https://red.libssh.org/issues/214

Because cmakeBuild.cmd gets the libssh-0.72.0 source code from svn://dev.exiv2.org/svn/team/libraries, I have updated these to include the fixes for 205 and 214. However, any 'vanilla' libssh bundle will not have these fixes.

I still have three remaining tasks:

1. get Jenkins to build and publish artefacts and logs
2. --static builds (not tested at all)
3. more testing