[CMake] ${PROJECT}-config.cmake

[Michael Hertling]

On 06/14/2010 12:09 PM, Biddiscombe, John A. wrote:
> Michael,
> 
> thanks for the feedback. Following the advice given, I've modified the project so that it generates an hdf5-config.cmake file, which checks for If(NOT target blah blah) and then loads the hdf5-targets.cmake file.

This seems to be a good occasion to ask the CMake developers some
questions concerning imported targets: In contrast to ordinary targets,
they're scoped, i.e. two sibling directories' CMakeLists.txt files may
add the same imported target without causing a conflict, but repeating
its definition within the same scope is forbidden. This results, e.g.,
in the need to protect the inclusions of a targets file generated by
INSTALL(EXPORT ...) as John has described. Now, I wonder if there is a
necessity to disallow multiple definitions of the same imported target
within the same scope or if this restriction could be casually dropped.

Regarding ordinary targets, the situation is slightly different: They
are defined once and globally in the project and one knows where they
are defined; thus, there's no need to repeat the definitions anywhere,
but imported targets must be imported at first from foreign projects,
so, e.g., an included package could have already imported them in the
current scope. To make things more convenient, would it be possible to
automatically protect the imported targets' definitions in the targets
file generated by INSTALL(EXPORT ...) using IF(NOT TARGET ...) along
with the associated properties in the configuration-specific files?

Furthermore, another question arises from Brad King's statement at
<http://www.mail-archive.com/cmake@cmake.org/msg18496.html>:

[...]
Imported targets should be scoped as the documentation states. The
reason is that different parts of a project may load the same package or
two different versions of the same package. They should remain isolated
from one another just like variable scopes are isolated.
[...]

This works if those parts of the project are siblings but fails if they
have an ancestry relationship. Currently, as far as I can see, a parent
directory and its subdirectories have no possibility to load the same
package involving imported targets independently. Therefore, I'd like
to ask if it would be feasible to make imported targets really scoped,
i.e. the latest definition hides - but doesn't touch - the previous
one and remains valid until hidden by a descendant's definition.

> I had one small problem which was generating one hdf5-config.cmake for the install directory, and  one for the build directory and getting paths correct, so that a user can use either the build version (testing etc) or the install (not users). Seemed like it was harder than it should be. Your point is noted that the time at which the targets files are created is not guaranteed, but for now all seems good.

Perhaps, you can use EXPORT(TARGETS ...) which generates a file similar
to the ones that result from INSTALL(EXPORT ...) but referring to the
targets' locations within the build tree and existing "officially"
before installation, and EXPORT(PACKAGE ...) could be of special
interest to you, too.

Regards,

Michael