Bug #994
CMake: wrong build rule for svn_version.h
100%
Description
Well I seem to be in a bad luck with this svn_version.h! Last time, it was another issue with the same file. :-)
Anyway so in src/CMakeLists.txt, there is the following rule lines 151-152:
CONFIGURE_FILE( ${CMAKE_CURRENT_SOURCE_DIR}/svn_version.h.in
${CMAKE_CURRENT_BINARY_DIR}/svn_version.h @ONLY)
Well that's not good since there is no file named svn_version.h.in in the source code, and no other rule to make such a file. I guess there was a change lately in the way svn_version.h is generated and you forgot to fix the CMake build.
The solution I found is to replace it with:
ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_BINARY_DIR}/src/svn_version.h
COMMAND ${CMAKE_SOURCE_DIR}/src/svn_version.sh)
I also change the line 160-161:
SET( LIBEXIV2_HDR ${LIBEXIV2_HDR}
${CMAKE_BINARY_DIR}/src/svn_version.h
)
Otherwise the build system tries to find the header in the source tree, not in the build tree.
Finally I got a problem that I could not solve, src/version.hpp has an include and it cannot find svn_version.h:
/home/jehan/dev/crossbuild/w64/exiv2-trunk/exiv2/version.hpp:44:25: fatal error: svn_version.h: No such file or directory
#include "svn_version.h"
Even modifying INCLUDE_DIRECTORIES this way won't fix the problem:
INCLUDE_DIRECTORIES(${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_BINARY_DIR}/src)
And I got stuck (I know autotools much better than CMake). I just moved the header to the build root for workaround for now, but obviously I know you'll find the real fix. :-)
Related issues
Associated revisions
#994 Update svn_version.h using svn info 'Last Changed Rev' instead of 'Changed'. This enables exiv2 -vVg svn to identify build branch or trunk.
#994 Update svn_version.h using svn info 'Last Changed Rev' instead of 'Changed'. This enables exiv2 -vVg svn to identify build branch or trunk.
History
Updated by Daniel Kaneider about 7 years ago
It seems that Robin forgot to commit the .in file from the patch in issue #993. The other parts of the CMake file are correct, svn_version.h is supposed to be in the binary directory.
Updated by Robin Mills about 7 years ago
I've just discovered this also. Adding svn_version.h has caused a LOT of problems. More trouble than it's worth. I don't know why svn_version.h.in wasn't committed. I'll do that now. I have to say that I don't understand what's wrong with svn_version.sh to generate/update this little file. The CMake solution is much more complicated than my original design.
Anyway, thanks for giving me a head's up about this.
Robin
Updated by Robin Mills about 7 years ago
- Status changed from New to Assigned
- Assignee set to Robin Mills
- Target version set to 0.25
Fix submitted: r3374
Thanks for the team work here. Good Job, guys. Apologies to Jehan for the inconvenience. Apologies to Daniel for not submitting svn_version.h.in. I was aware of svn_version.h.in and can't explain how it did not get added when I dealt with your patch. I am human and make mistakes!
I've done a successful out of source build/test on Linux and Mac. Cygwin's not linking correctly - seems to be failing to find xmpsdk/libxmp.a. I'll investigate later.
I'm developing a build server using Jenkins and it's visible at exiv2.dyndns.org:8080. This issue demonstrates why Jenkins is valuable. The build matrix of Exiv2 is now quite large and running build/tests on every commit will draw my attention quickly to this kind of defect. I'm working on this ... remember this isn't a full time job ... it's meant to be a hobby!
Updated by Robin Mills about 7 years ago
- Status changed from Assigned to Resolved
False alarm: Cygwin build is OK. I have a new Windows7 VM and it is not building correctly. The "old" Vista VM does build/test OK with ./configure and CMake (both Out-of-source and not out-of-source). I'm going to mark this "resolved". I'm not going to log an issue concerning Windows7 as I believe that's a local issue on my build machine.
Updated by Jehan Pagès about 7 years ago
Does not look like I have the capability to reopen this ticket. So I'll just write a message, hoping it will be seen. :-)
So today I tried a new build with updated tree. The svn_version.h.in is here. That's good.
But the second problem is still there:
In file included from /home/jehan/dev/crossbuild/w64/exiv2-trunk/exiv2/types.hpp:48:0,
from /home/jehan/dev/crossbuild/w64/exiv2-trunk/exiv2/basicio.hpp:34,
from /home/jehan/dev/crossbuild/w64/exiv2-trunk/exiv2/exiv2.hpp:34,
from /home/jehan/dev/src/exiv2-trunk/samples/addmoddel.cpp:5:
/home/jehan/dev/crossbuild/w64/exiv2-trunk/exiv2/version.hpp:44:25: fatal error: svn_version.h: No such file or directory
#include "svn_version.h"
^
compilation terminated.
I have to move the svn_version.h manually to root to have this work.
Updated by Jehan Pagès about 7 years ago
Oh and by the way, no problem for the whole hobby part. I don't complain. That's Free Software and I'm happy to contribute too. :-)
Updated by Jehan Pagès about 7 years ago
Oh and another problem with the `make install`! Still the same file:
CMake Error at src/cmake_install.cmake:55 (FILE):
file INSTALL cannot find
"/home/jehan/dev/src/exiv2-trunk/src/svn_version.h".
Call Stack (most recent call first):
cmake_install.cmake:49 (INCLUDE)
Obviously in my case since my build root is different from my source root. Are you doing all your builds from the source root by any chance? If so, that's why you may miss these kind of build bugs. :-)
Updated by Robin Mills about 7 years ago
- Status changed from Resolved to Assigned
Jehan
Thanks for updating this. And apologies for the trouble this is causing you. I regret adding SVN support stuff to the trunk as it has caused lots of unintended trouble.
I'm on vacation at the moment and get home November 18. I'll fix it. Thanks for speaking up about this.
Robin
Updated by Robin Mills almost 7 years ago
- Status changed from Assigned to Resolved
#994 Adding src/svn_version.h.in - apologies to Daniel for not committing this, and to Jehan for the inconvenience.