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' > time.
Ok. Still I'd prefer something similar to write_basic_config_version_file(), which creates a FooConfigVersion.cmake which is then installed using install(FILES). If somebody has that code already, add write_basic_config_file() and putting the resulting file in the same install(FILES ) call seems like a straightforward extension. > >> 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- > > [email protected] 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 Alex _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
