[cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree

[Stephen Kelly]

Daniele E. Domenichelli wrote:

> Sorry, I'm still not convinced by this... The "QT_USE_FILE" variable
> will have the same issue with relative paths and will have to be passed
> as absolute path to configure_package_config_file(), or am I missing
> something?

Are you missing the assumption that its location is constant relative to the 
config file? That makes ${CMAKE_CURRENT_LIST_DIR} appropriate.

>>> The second case is a path to a folder containing "data" files installed
>>> by the library (that usually go in <prefix>/share/<something>), and that
>>> other projects should be able to use.
>> 
>> I guess if you have a particular structure in the source tree, you might
>> not want to symlink/replicate it to the build tree. That arises for qml
>> files for example. However, usually I have chosen the symlink/copy route.
> 
> Symlinks are not really an option

I wrote 'symlink/replicate'.

> Another issue with copying the file is that the file is copied at CMake
> time, not a build time, and cmake is not triggered and therefore the
> copy is not performed at build time if the file is modified and the user
> just runs make (or "build" for visual studio and other IDEs).

CMake re-runs (as of a recent cmake version) if the input to configure_file 
changes.

> <off-topic>
> 
> By the way, is there a reason why file(COPY) does not have an option to
> copy the file only if the file(s) is(are) different.

configure_file(COPY_ONLY) does that. file(COPY_IF_DIFFERENT) would just do 
the same thing but would be more discoverable and might be a good idea.

> Since you were asking if CMake misses some important feature, I believe
> that a very useful feature to have would be to be able to have an option
> for the install(FILES/PROGRAMS/DIRECTORY) command that reproduces the
> install tree in the binary directory

Yes, seems like something worth investigating.

> , but at build time, and only if the
> destination file is missing or is different from the source.
> 
> Or maybe, using the export(FILES/PROGRAMS/DIRECTORY), like for the new
> export(EXPORT) command...

It might be worth filing a bug to record the full idea.

>>> and the
>>> relative path is different, since for the build tree the cmake config
>>> files are in ${CMAKE_BINARY_DIR} (as expected for example by the package
>>> registry)
>> 
>> Some other places you can have the cmake config file for the build tree:
>> 
>>  ${CMAKE_BINARY_DIR}/cmake
>>  ${CMAKE_BINARY_DIR}/<project-name>
>>  ${CMAKE_BINARY_DIR}/<project-name>/cmake
>>  ${CMAKE_BINARY_DIR}/cmake/<project-name>
>>  ${CMAKE_BINARY_DIR}/lib/cmake/<project-name>
>>  ${CMAKE_BINARY_DIR}/lib/cmake
>> 
>> Depending on whether you're going for 'cleanliness' or similarity to the
>> installed layout etc.
> 
> I wasn't aware of this, thanks for pointing it out... Maybe this needs
> some more documentation...

Actually, are you talking about export(PACKAGE)? I don't really know 
anything about that.

> The build directory is unlikely to be constructed as an "installation
> prefix", therefore I thought that these paths were not checked for a
> build tree.

Setting the CMAKE_PREFIX_PATH to contain the build dir would do it.

> Does this mean that if I set the <PACKAGE>_DIR environment variable to
> the CMAKE_BINARY_DIR of my package, CMake will look into these folders
> as well?

No, I don't think so. You would have to set it to the exact dir afaik.

> Anyway, conceptually one should recreate the install tree inside the
> build tree, and then generate just one config file using
> configure_package_config_file and use it both for build and install, is
> this correct?

In my preference, there should be no need to generate the config file, 
except to copy it from the source tree to the build tree. Then the content 
of that file is the same, yes.

My preference.

Thanks,

Steve.