Exiv2

Emmanuel

Apologies for the inconvenience. Our CMake/Visual Studio support isn't good. I'm hoping to get this solid and reliable for v0.26. As it says in 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. 

ToDo: * Fix out of source builds for NMake
      * Find and link iconv library on Windows
      * Test Cygwin, MinGW, Xcode, NMake and more versions of MSVC
      * Revisit searching for zlib, expat and iconv
      * Work on the "inherited from Gilles" list below

Fix submitted. r3948. Thanks for reporting this and providing a fix.

Hi guys,

No need for apologies, I'm glad that you already accepted the proposed fix.

It's hard for me to commit in maintaining the cmake part, because I only have access to a windows PC at work (I'm more on the *nix side at home). Anyway, I'm currently working with the cmake build system on both windows and linux, and I will fix and report any issue I find. Currently, version 0.24 did build pretty well on windows via cmake (we only had to force unicode support), and my issue-to-fix next week is related to the build output on linux (I couldn't detect more issues on windows).

I asked in the forum first, because we did update at the same time exiv2 and cmake (3.3.1). I'm not sure to understand why it the behavior of the FindZLib module is different from the behavior of other Find* modules, and I will also investigate that too.

Again, thanks for the reactivity!

Gosh, this is good news. Thanks. Daniel did some work on this a few months ago and I hope to give it more attention before v0.26 ships.

I worked on this a couple of years ago between contracts. I found it rather frustrating because the builds take such a long time and there are lots of versions of Visual Studio. I have committed to making our buildserver available to anybody and that will make it easier to request lots of builds. I started working on this last week and you can see the UI here: http://clanmills.com/exiv2/buildServer.html

The buildServer has been operational for about a year. It builds trunk and selected branches when code is submitted. If you have a user account, you can trigger a build. I hope to enable anybody to request a build (by SVN revision) and get all the build artefacts (libraries, logs, executables). http://exiv2.dyndns.org:8080

Hi everyone,

Thanks for the warm welcome!

Here is another patch submission. It will move the logic to enable the flag EXV_UNICODE_PATH (useful if you have wide strings on Windows) to the CMake configuration. The previous solution was based on detecting the environment (test for windows && not mingw && not cygwin). This solution was not reliable at all in our automated build system, so I chose to explicitly enable/disable this option in the cmake configuration. I chose to turn this option OFF by default to retain the previous behaviour, but it makes sense to have it ON by default if most of the windows users use MSVC instead of MinGW/Cygwin.

Hope this helps!

Thanks Emmanuel. Submitted r3958 and attributed to this CMake/Windows issue #1041. Let's bring this thread to a close and continue in #1041.

Hi, sorry for the late reply.

I will have to revert that initial change (r3948), since it makes no sense. Adding .lib to the target-link-library path may just be a workaround for missing paths. I know CMake on windows works quite differently than on Linux, such as you need to tell the system where the libraries are stored. One way is to do this using DCMAKE_LIBRARY_PATH, using install paths also works on linux.

Have a look at my scripts in contrib/build/msvc, they compile exiv2 out of the box from an empty directory. Set the right paths in setenv.bat (svn,cmake,cygwin), and then simply launch build from within a VC command prompt. The scripts might give you an idea how I generally use cmake on windows.

At least this works with my configuration including curl support (VC13, Win10, CMake 3.3.2)

Any doubts?

Thanks for getting involved in this Daniel. The conversation has moved to #1041. I thought Emmanuel and T were going to send me something this week, however that hasn't happened. If you want to revert r3948, I'm fine with that and T said it was wrong. However, Emmanuel needs it to get his CMake/Visual Studio 2013. I haven't been able to get anything to build with CMake 3.3.2/Visual Studio (2005, 2008, 2010, 2012, 2013 or 2015). I am totally frustrated by this.

I had a conversation with Gilles last weekend (#1123) and proposed that we adopt CMake as our primary build platform from v0.26 forward for *nix systems (Linux, Mac, Cygwin, MinGW). However I'd like to retain msvc2005 as the primary Visual Studio build environment. I have an open issue to do various enhancements to our Visual Studio support. #1121.

Gentlemen

I have good news. I had a meeting with on Skype with Daniel. Very productive meeting. I've copied his scripts and started modifying them. Mine are in contrib/cmake/msvc/ and there's a ReadMe.txt to explain how to use them. The scripts are now building exiv2 with zlib-1.2.8 and expat-2.1.0. In the next few days I'm going to work on the webready support which requires building openssl, libssh and curl.

If you don't require webready support, I'd appreciate feedback concerning my scripts.

I'm very optimistic that CMake/Visual Studio will work well in v0.26. Not too confident about building openssl with CMake. However Daniel had some way of getting that to work. So there's reason for optimism.

Robin