Making writing Config.cmake files easier - updated example
neundorf at kde.org
Tue Jan 17 17:26:02 UTC 2012
On Monday 16 January 2012, Yury G. Kudryashov wrote:
> Alexander Neundorf wrote:
> > On Sunday 15 January 2012, Yury G. Kudryashov wrote:
> >> 15 January 2012 20:06:51 Alexander Neundorf written:
> >> The only comment: there are 4 possible combinations of
> >> cmake -DLIB_INSTALL_DIR=relative_or_absolute -
> >> DINCLUDE_INSTALL_DIR=relative_or_absolute
> >> It seems that your library will not be relocatable if
> >> INCLUDE_INSTALL_DIR is set to an absolute path.
> > I think I can improve this a bit more, but yes, this may be a limitation,
> > but IMO an acceptable limitation.
> > If you want to create a relocatable package, don't set absolute paths.
> > (I know all install dirs are absolute with kdelibs4, this will change
> > with KDE frameworks).
> This can be solved if you store the original prefix in Config.cmake.
> >> Basically, my goal is a macro that writes and installs *Config.cmake
> >> files in "simple" cases and makes library available to find_package()
> >> both from another subdirectory of the same project and after
> >> installation. What do you think about this approach?
> > Looks quite good.
> > We must make sure that it doesn't keep developers from adding custom
> > stuff to the Config.cmake files. But this looks quite good with your
> > "EXTRA_VARS" and "EXTRA_CONFIG_FILE" options.
> > I think it may need a special option for specifying variables and values
> > which are directories (and so which have to be made absolute/relocated).
> Yes. I have a code for this but it needs a good syntax for both "internal"
> and "installed" version of Config.cmake.
> >> Actually, I'd prefer to have
> >> install(EXPORT ... ... INSTALL_CONFIG [bool] PACKAGE_NAME [=ExportName])
> > I see. Still, exactly the same is possible using install(FILES ...), so I
> > see the chances for getting this accepted into cmake as uncertain.
> > Oh, wait.
> > install_cmake_config_files() creates *and* installs the files ?
> install(EXPORT ...) generates Export file *and* installs it. So,
> install(CONFIG_FOR_EXPORT ...)
> can do the same. Actually, the file can be generated at 'make install'
Ok. Still I'd prefer something similar to write_basic_config_version_file(),
which creates a FooConfigVersion.cmake which is then installed using
If somebody has that code already, add
and putting the resulting file in the same install(FILES ) call seems like a
> >> install(EXPORT ...)
> >> config_for_export(ExportName VERSION ... VERSION_STRING ... EXTRA_VARS
> >> ...). What do you think about this?
> >> I cannot implement config_for_export() because I don't know how to query
> >> cmake for the list of targets associated with given export (is it
> >> possible?).
> > Within CMake, yes, from cmake script, I think no.
> Already looked at cmake code. One of the possible solutions is to add
> "properties" to export sets in C++ cmake code and implement the rest in
> cmake scripts.
> > Having said all that, please send your proposal again, but to the cmake-
> > developers at cmake.org list.
> > Whatever solution we get to, I want to have it in cmake 2.8.8,
> What are deadlines for cmake-2.8.8 feature commits?
Around end of February
More information about the Kde-buildsystem