Feature #1031
CMake build broken when using zlib/expat in clean way
100%
Description
Hi,
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.
Regards,
Daniel
Files
Related issues
Associated revisions
#1031 Thank You Daniel for the patch. This submission is on the trunk.
#1031. CMake documentation update for v0.25. No major work is planned for CMake in v0.25.
History
Updated by Robin Mills almost 7 years ago
- Status changed from New to Assigned
- Assignee set to Robin Mills
- Priority changed from High to Normal
- Target version set to 0.25
Updated by Robin Mills over 6 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 over 6 years ago
Thank You, Daniel for the patch. I've submitted it on the trunk. r3613
Updated by Robin Mills over 6 years ago
- Tracker changed from Bug to Feature
- Status changed from Assigned to New
- Assignee deleted (
Robin Mills)
Updated by Robin Mills over 6 years ago
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.
Updated by Robin Mills about 6 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.
#1031. CMake development. Builds OK on Mac.