ECMQtFramework.cmake, version header and ECMWriteVersionHeader.cmake
Alexander Neundorf
neundorf at kde.org
Mon Aug 13 20:54:11 UTC 2012
Hi,
I just added a ECMWriteVersionHeader.cmake to e-c-m, it is not used anywhere
yet.
It is used like this:
ecm_write_version_header(${CMAKE_CURRENT_BINARY_DIR}/itemmodels_version.h)
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/itemmodels_version.h
DESTINATION ${INCLUDE_INSTALL_DIR} COMPONENT Devel )
Currently this configure_file() call is part of ECMQtFramework.cmake.
I'd like to remove it from ECMQtFramework.cmake and add this explicit call
instead everywhere.
This will make it obvious that such a version header is generated and should
be installed.
I'm not sure this is already the final form I'd like to have (actually I don't
think so), but IMO it is a step in the right direction.
With this configure_file() moved out from ECMQtFramework.cmake,
ECMQtFramework.cmake basically only deals with generating and installing
Config.cmake files and the exports sets.
I think at this point we are getting much closer to a state where less magic
happens and things get more obvious. Probably in a next step the file can be
renamed (because it doesn't have anything Qt-specific anymore, and I'm also
not sure we should use the term "Framework" here, since this may very well be
mixed up with OSX frameworks by cmake users).
So, objections to using ECMWriteVersionHeader.cmake everywhere ?
Also, the generated version headers in kdelibs are only installed in a few
places, most remain uninstalled. Is this intentionally ?
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20120813/e4586656/attachment-0001.html>
More information about the Kde-buildsystem
mailing list