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