[CMake] Creating relocatable packages

Mon Oct 19 19:02:23 EDT 2015

Yes, Pau, this is exactly my problem. Or more specifically, as the author
of a library that uses CMake and depends on libpcap, how can I best
structure and distribute the library to make it easy to use (and cross
compile)?  I would say using the system libpcap is strongly preferred over
distributing a copy of it.

That tutorial is very interesting.  I'll have to take a closer look at it
because the solution isn't jumping out at me.  The tutorial shows a project
that contains both a library and a program that links to that library in
the same list file.  In my case that would not be possible.  Also, the
library in the example has no dependencies so it wouldn't suffer from the
absolute path issue I'm encountering.
On Oct 19, 2015 5:36 PM, "Pau Garcia i Quiles" <pgquiles at elpauer.org> wrote:

> Hi Dan,
>
> On a second read, it seems Zac's problem was actually finding the
> dependency (libpcap) of a dependency. Or rather, making if findable,
> because the second depenency contains an absolute path which is broken due
> to cross-compilation.
>
> I have never used it but this page contains information on how to fix the
> paths in the config file to be relative instead of absolute. That should
> fix the problem:
>
>
> https://cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file
>
>
>
> On Mon, Oct 19, 2015 at 11:15 PM, Dan Kegel <dank at kegel.com> wrote:
>
>> Well, that's one answer.  But if you want to use system libpcap, it's not
>> a very satisfying one.
>>
>> It's odd that pcap doesn't ship with a .pc file.
>> I guess the pcap folks are hostile to pkgconfig because it's LGPL; see
>> https://github.com/the-tcpdump-group/libpcap/issues/374
>> - Dan
>>
>>
>>
>> On Mon, Oct 19, 2015 at 2:04 PM, Pau Garcia i Quiles <
>> pgquiles at elpauer.org> wrote:
>>
>>> Hello,
>>>
>>> Use ExternalProject to build libpcap as part of your project. Make sure
>>> you use $ORIGIN in rpath everywhere. Install your application (and your
>>> bundled libpcap) to /opt to avoid polluting the system.
>>>
>>> On Mon, Oct 19, 2015 at 10:37 PM, Zac Bergquist <zbergquist99 at gmail.com>
>>> wrote:
>>>
>>>> Thank you for your reply, Guillaume.
>>>>
>>>> I understand that this is the expected behavior.  I even linked to the
>>>> documentation that says this is the expected behavior.  What I don't
>>>> understand is how to resolve it.  Are you saying it is not possible to
>>>> create a relocatable package unless all dependencies are also using CMake?
>>>> That doesn't seem right.
>>>>
>>>> Should I be trying to write a package config file for libpcap, or is
>>>> there a better way to approach this?
>>>>
>>>> On Sat, Oct 17, 2015 at 8:19 AM, Guillaume Dumont <
>>>> dumont.guillaume at gmail.com> wrote:
>>>>
>>>>> What you are seeing is the expected behavior. You can get a
>>>>> relocatable package if all your dependencies (in your case libcap) have
>>>>> themselves relocatable package config files with exported targets. Then you
>>>>> package should make use of find_dependency macro.
>>>>>
>>>>> On Fri, Oct 16, 2015 at 4:56 PM, Zac Bergquist <zbergquist99 at gmail.com
>>>>> > wrote:
>>>>>
>>>>>> I've created a sample project to replicate my issue in hopes that it
>>>>>> would make it easier to troubleshoot.
>>>>>>
>>>>>> Thanks for any help,
>>>>>> Zac
>>>>>>
>>>>>> https://github.com/zmb3/cmaketest
>>>>>>
>>>>>> On Mon, Oct 12, 2015 at 8:53 AM, Zac Bergquist <
>>>>>> zbergquist99 at gmail.com> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I'm trying to fix a project so that its output is relocatable.  The
>>>>>>> project is a library that itself depends on libpcap.  My goal is to be able
>>>>>>> to import the library into my CMake application and have CMake
>>>>>>> automatically link libpcap with it.
>>>>>>>
>>>>>>> I'm using a toolchain file that invokes an ARM cross compiler, sets
>>>>>>> CMAKE_INSTALL_PREFIX and appends it to CMAKE_FIND_ROOT_PATH.  This all
>>>>>>> seems to work well.
>>>>>>>
>>>>>>> What I'm seeing is that the exported files that get installed to
>>>>>>> CMAKE_INSTALL_PREFIX contain absolute paths to libpcap on my machine, which
>>>>>>> make them useless to other team members.
>>>>>>>
>>>>>>> The first thing I changed was to use CONFIGURE_PACKAGE_CONFIG_FILE
>>>>>>> instead of CONFIGURE_FILE.  This got rid of absolute paths in the generated
>>>>>>> CMake config file.
>>>>>>>
>>>>>>> However, I still have absolute paths in the CMake target import file
>>>>>>> that gets generated.  The IMPORTED_LINK_INTERFACE_LIBRARIES target property
>>>>>>> has an absolute path instead of one relative to CMAKE_INSTALL_PREFIX.
>>>>>>>
>>>>>>> I've read the "Creating Relocatable Packages" [1] section of the
>>>>>>> CMake packages documentation. I'm pretty sure this is what I'm running
>>>>>>> into, but I don't quite understand how to solve it.  The documentation says
>>>>>>> that I should be using imported targets, but I'm not sure how to do so.
>>>>>>> The library is just using its own FindPCAP.cmake file to locate libpcap.
>>>>>>>
>>>>>>> Does anyone know of an example of a CMake package that imports other
>>>>>>> libraries?  I could also try to create a minimal example project with this
>>>>>>> setup if it would be helpful.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Zac
>>>>>>>
>>>>>>> [1]:
>>>>>>> https://cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html#creating-relocatable-packages
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Powered by www.kitware.com
>>>>>>
>>>>>> Please keep messages on-topic and check the CMake FAQ at:
>>>>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>>>>
>>>>>> Kitware offers various services to support the CMake community. For
>>>>>> more information on each offering, please visit:
>>>>>>
>>>>>> CMake Support: http://cmake.org/cmake/help/support.html
>>>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>>>>
>>>>>> Visit other Kitware open-source projects at
>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>
>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>> http://public.kitware.com/mailman/listinfo/cmake
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Guillaume Dumont
>>>>> =========================
>>>>> dumont.guillaume at gmail.com
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Powered by www.kitware.com
>>>>
>>>> Please keep messages on-topic and check the CMake FAQ at:
>>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>>
>>>> Kitware offers various services to support the CMake community. For
>>>> more information on each offering, please visit:
>>>>
>>>> CMake Support: http://cmake.org/cmake/help/support.html
>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://public.kitware.com/mailman/listinfo/cmake
>>>>
>>>
>>>
>>>
>>> --
>>> Pau Garcia i Quiles
>>> http://www.elpauer.org
>>> (Due to my workload, I may need 10 days to answer)
>>>
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/cmake
>>>
>>
>>
>
>
> --
> Pau Garcia i Quiles
> http://www.elpauer.org
> (Due to my workload, I may need 10 days to answer)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20151019/7d62fc9c/attachment-0001.html>