[cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree

[Daniele E. Domenichelli]

On 23/07/14 20:39, Brad King wrote:
> Returning to CMakePackageConfigHelpers, I work on several projects
> that provide one <pkg>Config.cmake file in the build tree and one
> in the install tree.  They are generated by hand.  I do not use
> CMakePackageConfigHelpers.  IMO it is good for getting projects
> started without having to learn all the details.  For mature projects
> that want to do fancy things like supporting applications from the
> build tree, manual generation of the package configuration files
> becomes worthwhile.

Sorry if I insist, but I still don't understand why not allowing to be
able to use CMakePackageConfigHelpers for the build tree, and I still
cannot find a valid alternative therefore I'll do a last desperate
defence of my patch to try to convince you and Steve. ;)


I think that it is good for new projects to be able to use the build
tree before actually testing the installation of the project, as this
will speed up the development process. From my experience, the
installation step is finalized later in the creation step of a library.

'configure_package_config_file()' allows you to do whatever you want in
your input config file, exactly like 'configure_file()', but it is still
very helpful for handling relative paths correctly. I agree that
"perfect" config files should not contain paths, but I believe that if
no paths should be in the config file, then
'configure_package_config_file()' does not make not much sense neither
for mature nor new projects (except for simplify the handling of
components) and perhaps should be deprecated or replaced by something
else. On the other hand if paths are acceptable be in the config files
(as relative paths), then I don't see why generating them in the same
way both for build and install tree shouldn't be allowed, and I believe
that there are several valid use cases where the paths are required.

I work too on several projects that provide one <pkg>Config.cmake file
in the build tree and one for the installation, but they use paths, and
the paths in the installed files are absolute.
I'm working on porting them to a "modern" CMake style, but I cannot
suddenly drop compatibility with older versions, and I cannot drop the
path variables from the config files.
Moreover I cannot push the dependency on the latest CMake and I'm stuck
with 2.8.9, that misses several of the new features required for a full
"modern" CMake style are still missing, thus the paths are necessary.

Therefore for now I'm trying to port them to use relative paths, in
order to simplify the creation of the installers for Windows, and this
led to trying to port them from configure_file() to
configure_package_config_file().
Unfortunately I cannot but drop compatibility with having a working
build tree.

The result is that I had to choose between these options (I couldn't
find any other option, but I'm still open to different solution if you
can think one):
1) Not using CMakePackageConfigHelpers and keep using configure_file
   with the absolute paths
2) Using two different input files and two different calls.
3) Pay very good attention to pass only absolute path to
   configure_package_config_file, and keep an "ugly" config file in the
   build directory with PACKAGE_PREFIX_DIR pointing to the
   CMAKE_INSTALL_PREFIX, and the variables with absolute path. As I
   mentioned before, this works, but it is error prone because using
   relative path will result in a broken config file.
4) Use a hack like (this actually works, but it looks horrible to me
   and require an explaination comment wherever you use it...)
     set(_CMAKE_INSTALL_PREFIX "${CMAKE_INSTALL_PREFIX}")
     set(CMAKE_INSTALL_PREFIX "${CMAKE_BINARY_DIR}")
     configure_package_config_file(...)
     set(CMAKE_INSTALL_PREFIX "${_CMAKE_INSTALL_PREFIX}")
     unset(_CMAKE_INSTALL_PREFIX)
5) Ship a modified version of CMakePackageConfigHelpers with my project.


All these options seem bad to me, therefore I went for the "cleanest"
solution, i.e. get the patch merged upstream, in order to ship with my
projects the update "official" CMakePackageConfigHelpers module that I
will remove when I can finally depend on the version that will contain
the patched version.


Anyway, if I still didn't convince you, at least now nobody can say I
didn't try...  ;)

Do you want me to drop the patch and push the restructured documentation
in a new topic?


Cheers,
 Daniele


P.S. Sorry for the long mail