Modified build system for itemmodels

Alexander Neundorf neundorf at kde.org
Thu May 3 20:41:16 UTC 2012


On Wednesday 02 May 2012, Alexander Neundorf wrote:
...
> I'm not at all against making Config.cmake files easier to create. But it
> should not make it in any way harder to add project-specific information to
> them (which IMO already happens if you end up with a somewhat working
> version without doing anything).
> 
> 
> How about something like this:
> 
> 
> set(FOO_INSTALL_DIR ${CMAKE_INSTALL_PREFIX})
> set(FOO_INCLUDE_DIR include)
> set(FOO_DATA_DIR share/foo/ )
> set(FOO_WITH_Bat ${OPTION_BAT_ENABLED})
> set(FOO_WITH_Blub ${OPTION_BLUB_ENABLED})
> set(FOO_LIBRARIES "KF5::Foo;KF5::Blub")
> 
> ecm_write_basic_config_file(${CMAKE_BINARY_DIR}/FooConfig.cmake
>                   PATH_VARS     FOO_INSTALL_DIR FOO_INCLUDE_DIR
> FOO_DATA_DIR OTHER_VARS    FOO_WITH_Bat FOO_WITH_Blub FOO_LIBRARIES
> TARGETS_FILE  FooLibraryTargets.cmake )
> 
> 
> This could create a Config.cmake which handles the given PATH_VARS
> correctly, and which also sets the given OTHER_VARS to the values as they
> were when the macro was called.
> 
> This way we would not need a Config.cmake.in for every project.

attached are prototypes.

Please have a look (ignore the version-related stuff for now).

The Use-file is not there anymore, and the Config.cmake.in file is not there 
anymore.
Instead it is now generated using the new function 
ecm_write_basic_package_config_file(), which fits in style with  
write_basic_package_version_file().

This way the developer only has to care about which information he wants to 
put into the Config.cmake file, but does not have to care about more details 
anymore.
This is also generic enough to be put into e-c-m or directly into cmake IMO.


Do you have a suggestion for what to do with the version stuff ?
You had more things in mind than the trivial version header as it is now.


Maybe all that (creating the config file, creating the config version file, 
exporting the targets, installing those cmake files, creating the version 
header) can then be put all together into one big macro:

kde_setup_package_stuff(NAME itemmodels
                 INSTALL_DESTINATION ${CMAKECONFIG_INSTALL_PREFIX}/itemmodels/
                 PATH_VARS    itemmodels_INCLUDE_DIR itemmodels_INSTALL_PREFIX
                 OTHER_VARS   itemmodels_LIBRARIES itemmodels_HAVE_Foo                            
                 EXTRA_CONFIG_STRING "#something more for the Config file"
                 VERSION_VAR  itemmodels_VERSION_STRING
                 COMPATIBLITY AnyNewerVersion
                 VERSION_HEADER ${CMAKE_BINARY_DIR}/itemmodels_version.h
                 EXPORTS  ItemModelsTargets )


Not sure whether this would be nicer.


Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ECMWriteBasicPackageConfigFile.cmake
Type: text/x-cmake
Size: 1937 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120503/1f480e8c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itemmodelsConfig.cmake
Type: text/x-cmake
Size: 1031 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120503/1f480e8c/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CMakeLists.txt
Type: text/x-cmake
Size: 2283 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120503/1f480e8c/attachment-0002.bin>


More information about the Kde-frameworks-devel mailing list