Making writing Config.cmake files easier - updated example

[Alexander Neundorf]

On Tuesday 17 January 2012, Yury G. Kudryashov wrote:
> Alexander Neundorf wrote:
> > 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.
> 
> I have to know the DESTINATION at generation time to hardcode correct
> relative paths.

They can be calculated too, see the determine_installed_location() macro in 
the branch ImprovedConfigDotCMakeFile in git in kdeexamples.

Alex