[CMake] How to make a ProjectConfig.cmake

[Ian Monroe]

On Thu, Dec 30, 2010 at 09:42, Michael Wild <themiwi at gmail.com> wrote:
> 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.

Yes, I know how build systems work. But if some library that I depends
on changes where it is installed, that very well might not matter at
all to running my application. And mostly certainly not to building
it.

...yet the EXPORT-created cmake would still refer to this old file.
Maybe it doesn't really matter, just seems like bad practice to be
referring to files that aren't yours in these cmake files that get
installed.

Ian