[CMake] Best practices/preferred methods for linking external libraries

David Cole david.cole at kitware.com
Tue Dec 6 13:00:07 EST 2011


On Tue, Dec 6, 2011 at 12:08 PM, Matthew LeRoy <MLeRoy at minitab.com> wrote:
> On 2011-12-03 14:54-0800 Alan W. Irwin wrote:
>>
>> On 2011-12-03 12:42-0800 Alan W. Irwin wrote:
>>
>> > On 2011-12-02 19:33-0000 Matthew LeRoy wrote:
>> >> Assuming we want to just put the install tree in version control
>> >> somewhere, and have ProjectB's list files reference the install tree
>> >> out of version control, is writing a Find module the best way to do
>> >> that?
>> >
>> > I don't see any way your highly unusual use case could work unless you
>> > adopt a common installation prefix for projectA that everybody can use
>> > on their various systems.
>>
>> Hi Matt:
>>
>> On second thought I got too negative about your strange use case, and to
>> answer your question directly for that case, yes, with a Find module written
>> for ProjectA,  then your ProjectB users can install ProjectA anywhere, and if
>> they set CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH properly, they _should_ be
>> able to get the Find module to find libraries, headers, etc., from ProjectA
>> regardless of where it is installed.
>>
>> That said, I am still a little surprised you are not taking the traditional
>> independent software package approach for ProjectA.
>>
>> Alan
>
> Alan:
>
> I explained a little further (hopefully clearer?) what I'm trying to accomplish
> in another reply, here: http://www.cmake.org/pipermail/cmake/2011-December/047897.html.
>
> A further clarification would be that ProjectA is not intended to be distributed
> publicly on it's own at all; it will only ever be distributed as part of another
> project which uses it (ProjectB, for example). Essentially, it's just an independent,
> reusable sub-component that we want to develop in isolation.
>
> Here's something like what I was envisioning with putting the binary distribution
> in the source tree for ProjectB (many things omitted):
>
> /ProjectB
> |--CMakeLists.txt
> |--/src
> |--/test
> `--/lib
>   |--/bin
>   |  `--libProjectA.so
>   `--/include
>      `--/ProjectA
>         `--*ProjectA headers here*
>
> The idea, then, would be that whenever we want B to use a new version of A,
> we just drop the new .so and includes for A overtop of the existing ones in the
> source tree and commit them.
>
> So, the question is, what's the best way to get B's CMakeLists.txt files to find
> and use A from within B's own source tree? A Find*.cmake module for A?
>
> Or, do you recommend a different approach entirely?
>
> Matt
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake

You don't need a Find* anything for a scenario like this.

The best way to do this is simply to encode the knowledge of the
location of A's files in your B project CMakeLists files.


HTH,
David


More information about the CMake mailing list