[CMake] How to make a ProjectConfig.cmake

[Michael Wild]

On 12/30/2010 03:34 PM, Ian Monroe wrote:
> 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.

If the paths on the build server don't match the ones on the destination
system, then that distro is broken. Period. Here's what happens in the
case of Debian/Ubuntu/...:

- A minimal installation is unpacked from a tar-ball
- The system chroots into the unpacked system
- All dependencies are installed into the build environment
- The package is built
- The system exits the chroot, retrieves the package and discards the
build environment

This is to guarantee that the dependencies are set up correctly and that
no strange interferences occur.

> 
> ...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. :)

VTK, although that might not be the simplest example.

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

That's the CMake-way of doing things. Also, if you do things right,
creating e.g. a proper Debian package is going to be almost trivial
using CDDBS.


Michael