CMake build broken when using zlib/expat in clean way
once again, I tried to upgrade the exiv2 library used in our project. And, surprise, surprise, CMake compilation was broken again. I hoped that the project would finally switch to support CMake as the main toolchain, but anyway.
The first problem was, that the compiler didn't honor any more our zlib version. We are using 1.2.8. The build scripts set it hardcoded to 1.2.7
Second problem, the compiler seems to have a problem with the expat library. I'm not sure where the root cause is, but your scripts seem to set the expat library hardcoded, once again.
I'm building using
cmake.exe -G "Visual Studio 11 Win64" -DCMAKE_PROGRAM_PATH=%SVN_DIR% -DZLIB_ROOT=..\zlib-%ZLIB_COMMIT%;..\zlib-%ZLIB_COMMIT%\Release -DCMAKE_INCLUDE_PATH=..\expat-2.1.0\lib -DCMAKE_LIBRARY_PATH=..\expat-2.1.0\%Configuration% -DEXIV2_ENABLE_BUILD_SAMPLES=OFF -DEXIV2_ENABLE_CURL=OFF -DEXIV2_ENABLE_SSH=OFF
I discovered that commit 3479 broke a lot of things, my appended patch tries to solve at least those ones.
Updated by Robin Mills over 4 years ago
- Target version changed from 0.25 to 0.26
I'm going to look at this on branches/jenkins. I don't want to disturb the trunk at this time. The submission r3612 includes the code in your patch.
Submission r3479 was a very large submission to integrate the 'webready' code from Tuan's GSoC2013 project. That r3479 breaks the CMake build environment is regrettable. However, we have never claimed that our CMake support is ready for general use. Our CMake/MSVC support is weak. There are many challenges with CMake including: different platforms, in/out of source. You will be aware that CMake and MSVC are not happy bed-fellows. To compound this, nmake and the Visual Studio IDE present separate challenges.
It's not possible to move to CMake as our primary build platform at this time. At the team meeting in July 2015, it was agreed that the build project for v0.25 was to implement a build server. That project is mostly complete and operational. I'd like to complete the build server project before doing more work on CMake.
I'm willing to make small changes to the CMake files on the trunk, however moving to CMake as our primary (or even secondary and supported) build chain cannot be undertaken at the moment. I'd like very much to recruit a CMake Engineer to take on this task, however I haven't had the good fortune to do this yet.
I appreciate your offer (by private email) to provide CMake consultancy and I'd like to take advantage of your knowledge while not consuming lots of your time.
I've advanced the 'Target Version' of this issue to v0.26.
Updated by Robin Mills about 4 years ago
- Status changed from New to Closed
- Assignee set to Robin Mills
- % Done changed from 0 to 100
This issue is being closed because I am working with Emmanuel and T in #1041 to resolve CMake/Visual Studio issues. Both Emmanuel and T are optimistic of success. My loathing of CMake/Visual Studio is complete and expressed in #1041. I don't believe CMake can reliably build any code using Visual Studio.