[cmake-developers] Making Config.cmake files easier to write

Brad King brad.king at kitware.com
Wed Feb 15 17:19:23 EST 2012


On 2/15/2012 4:50 PM, Alexander Neundorf wrote:
> Ok, a working ConfigureConfigFile.cmake is attached, together with example
> files, input and the configured output and the driving CMakeLists.txt.

Nice!

Alternative name ideas:

   CMakePackageHelper     [1]
   ConfigureCMakePackage
   ConfigureCMakePackageFile
   ConfigurePackage
   ConfigurePackageFile
   ConfigurePackageConfig

[1] Generic name for helper APIs so we can add more macros later.
In this case the macro can perhaps be called:

   cmake_package_config

> The call now looks like this:
>
> configure_config_file(BarConfig.cmake.in
> ${CMAKE_CURRENT_BINARY_DIR}/BarConfig.cmake
>                        INSTALL_DESTINATION "${CMAKECONFIG_INSTALL_DIR}"
>                        PATH_VARS INCLUDE_INSTALL_DIR
>                                  BIN_INSTALL_DIR
>                                  FOO_INSTALL_DIR ...
>                       )

Good.  Note that configure_file automatically treats a relative path
for the output file w.r.t. the build tree.  Therefore the second arg
can be just "BarConfig.cmake".

> and in the Config.cmake.in file you have to put:
>
> @CONFIG_HELPER_DIRS_INIT@

Good.  Did you consider other prefixes?  I'm okay with CONFIG_HELPER_
but I wonder if there is something better.  Alternatively it could
be configured by an option to the macro.

> set_and_check(BAR_INCLUDE_DIR "@CONFIG_HELPER_INCLUDE_INSTALL_DIR@")
> set(BAR_DATA_DIR    "@CONFIG_HELPER_DATA_INSTALL_DIR@")
> The set_and_check() macro is provided by the @CONFIG_HELPER_DIRS_INIT@, it
> sets the variable and checks that the given directory or file exists.

Okay.  The set_and_check macro is perhaps overkill.  I've never
done an explicit existence check on such directories in a package
configuration file.  Let's not mix that into this feature yet.
I don't feel strongly about this though because a user can always
not use it.

> IMO it's a bit much macro magic.

IMO it's simpler than your previous proposal.  It is better for
all the magic to be at configuration time and not at load time.

Thanks,
-Brad



More information about the cmake-developers mailing list