[CMake] How to make a ProjectConfig.cmake

[Ian Monroe]

On Thu, Dec 30, 2010 at 08:08, Michael Hertling <mhertling at online.de> wrote:
> On 12/30/2010 11:33 AM, Ian Monroe wrote:
>> To create my QyotoConfig.cmake I need to know the full path of a
>> library so that I can set a variable like QYOTO_LIBRARY.
>>
>> This is pretty standard requirement right? Its what we're supposed to
>> do in *Config.cmake's?
>
> Yes.
>
>> So anyways, how do I that? The only target property that hasn't
>> returned NOTFOUND is LOCATION, which unhelpfully returns the location
>> of the library in the build directory. I could parse this to get the
>> file name, and then append it to the library install location... but
>> that seems like such a hack. Feels like I'm doing something wrong if I
>> need to use a hack to do something standard.
>
> Usually, I'd have a template QyotoConfig.cmake.in which contains
>
> FIND_LIBRARY(QYOTO_LIBRARY qyoto
>    PATHS @CMAKE_INSTALL_PREFIX@/lib
>    NO_DEFAULT_PATH
> )
>
> and is processed by CONFIGURE_FILE(). If the library is installed with
>
> INSTALL(TARGETS qyoto
>    RUNTIME DESTINATION bin
>    LIBRARY DESTINATION lib
>    ARCHIVE DESTINATION lib
> )
>
> the FIND_LIBRARY() in the resulting QyotoConfig.cmake file will find
> the library right at the installation location but nowhere else, and
> the platform-dependent file names, e.g. libqyoto.so versus qyoto.dll,
> are also handled correctly.
>
>> I looked at install(EXPORT which could work, but it seems to include a
>> lot more information then is needed. I just want to set a variable
>> with the full path to a library.
>
> Nevertheless, the imported-targets approach, i.e. the combination of
> INSTALL(TARGETS ... EXPORT ...) and INSTALL(EXPORT ...) along with an
> appropriately set up config file, is much more powerful and should be
> preferred, IMO; see [1] for more information. BTW, as the export file
> defines the imported targets, its inclusion in the config file should
> possibly be protected in a suitable way to avoid fatal redefinitions.

The context I'm coming from is that I'm developing stuff that is
distributed by Linux distributions. The export file has information
about what the target is dependent on, including full paths. That
feels like a bad thing to me. What was true about dependencies when a
package was being built on a build server might not be true later.

...or maybe its fine? Can someone point me to an example of a package
distributed by linux distros that uses this feature? Would make me
feel better to know that I'm not the first person to use it. :)

I'll probably go with your first solution, but this export feature is
interesting since it looks less cumbersome to use.

Thanks,
Ian