Making writing Config.cmake files easier - updated example

Yury G. Kudryashov urkud.urkud at gmail.com
Mon Jan 16 20:58:47 UTC 2012


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' time.

>> or
>> 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?
> not in somewhere in KDE.
I see. I'll send a proposal tomorrow.
-- 
Yury G. Kudryashov,
mailto: urkud at mccme.ru



More information about the Kde-buildsystem mailing list