Making writing Config.cmake files easier - updated example

[Alexander Neundorf]

On Sunday 15 January 2012, Yury G. Kudryashov wrote:
> 15 January 2012 20:06:51 Alexander Neundorf written:
> > Hi,
> 
> Hi,
> 
> Try #1 awaits moderator approval and can be safely deleted.
> 
> > I create a new branch ImprovedConfigDotCMakeFile in the kdeexamples
> 
> > repository, used by the buildsystem/HowToInstallALibrary/ example:
> http://quickgit.kde.org/?p=kdeexamples.git&a=tree&h=9c8e84b16079b35f15c50ea
> 0
> 
> 27bbc95bd387bf90&hb=6caa67be56231d3017859a26db2097b8c8826f4e&f=buildsystem/
> H
> 
> > owToInstallALibrary
> > 
> > It adds two new macros, currently called determine_installed_location()
> 
> and
> 
> > set_absolute() which should help with that.
> > Once polished, they should go into cmake (2.8.8), so everybody can use
> > them.
>
> 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).

> > With these two new macros, the developer does not have to calculate the
> > relative and absolute paths himself anymore, but can rely on their logic.
> > Also the CMakeLists.txt becomes a bit simpler, by removing the IMO most
> > obscure part (the calculation of the relative install dir).
> > 
> > Comments ?
> 
> I'm working on another way to solve the same problem. I'll commit results
> to kdeexamples tonight or tomorrow.
> 
> 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).

> The proposed syntax is:
> 
> install_cmake_config_files(Package
> LIBRARY_TARGETS (target|NAME=target)+ [EXECUTABLE_TARGETS (NAME=target)+]
> [VERSION version=PACKAGE_VERSION] [VERSION_STRING <var|value>]
> [EXPORT_NAME name=Package] [EXPORT_NAMESPACE ns="" or Package?]
> [DESTINATION destination=platform-specific default]
> [INSTALLED_INCLUDES dirs=${INCLUDE_INSTALL_DIR} or
> ${CMAKE_INSTALL_INCLUDEDIR}]
> [BUILD_INCLUDES dirs=${CMAKE_CURRENT_SOURCE_DIR}]
> [EXTRA_VARS (name|name=value)*] [EXTRA_CONFIG_FILE file])
> 
> The macros will:
> 0. Set all unspecified parameters to sane defaults, so in many cases you'll
> just have to set package name, LIBRARY_TARGETS, EXPORT_NAME and
> EXPORT_NAMESPACE. BTW, is it possible to query which EXPORT does the given
> target belongs to? 

I think no. What would you need it for ?

> Usage example:
>  // Add EXPORT LibKexiv2 to kexiv2 target and
>   INCLUDE(MacroWriteConfigFile)
>   INSTALL_CMAKE_CONFIG_FILES(LibKexiv2
>                        VERSION ${KEXIV2_LIB_VERSION}
>                        VERSION_STRING ${KEXIV2_LIB_VERSION_STRING}
>                        EXPORT_NAMESPACE LibKexiv2::
>                        TARGETS kexiv2)
> 
> 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 ?
Functions where you need an "and" to decsribe what they do are not good...
I think I'd prefer a version which would just create the file, and then you 
can do with it whatever you want. I.e. call install(FILES ...)

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

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, not in 
somewhere in KDE.

Alex