Modified build system for itemmodels

[Alexander Neundorf]

On Sunday 06 May 2012, Alexander Neundorf wrote:
> On Sunday 06 May 2012, Stephen Kelly wrote:
> > Alexander Neundorf wrote:
> > > 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.
> > 
> > I think this is a good goal.
> > 
> > > 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 )
> > 
> > The size of this is scary to me. There are so many arguments (even though
> > they are named), that I don't know where to begin with it.
> 
> Yes, it's a lot, but I think there is no redundancy left.
> "itemmodels" appears multiple times, but it doesn't increase the number of
> arguments.

Here we are again...
CMake can now export targets in separate export sets with the coming 2.8.10.

Additionally to all what we discussed here already, this means that when 
creating a Config.cmake file, this file should either check whether the 
required other packages (which created the needed imported targets) have been 
found or find_package() them.
So, this adds another information which needs to be put into the Config.cmake 
file, and which really is project-specific.

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
        VARS            FOO_WITH_Bat FOO_WITH_Blub FOO_LIBRARIES
        NEEDED_PACKAGES Bar;Blub
        TARGETS_FILES   FooLibraryTargets.cmake;FooOtherTargets.cmake)


An alternative way to do this would be:

set(ECM_PATH_VARS  FOO_INSTALL_DIR FOO_INCLUDE_DIR
                   FOO_DATA_DIR)
set(ECM_VARS       FOO_WITH_Bat FOO_WITH_Blub FOO_LIBRARIES)
set(ECM_NEEDED_PACKAGES Bar;Blub)
set(ECM_TARGETS_FILES FooLibraryTargets.cmake;FooOtherTargets.cmake)

include(ECMSetupConfigStuff)


but I prefer the first version.

Alex