[CMake] Proper way to export a library

[Cyrille Faucheux]

Ok, great.

Can you tell me a bit more about "implicit compile flags [...] for imported
tagets"?

On the library I'm currently working on, with Visual Studio, I have to
declare some compile definition in order to get the proper
"__declspec(dllimport)" or "__declspec(dllexport)" defined (or not defined
when compiling/using a static version of this library).

Does "implicit compile flags" means that those compile definition could be
automatically declared by the imported target?


2013/10/30 Matthew Woehlke <matthew.woehlke at kitware.com>

> On 2013-10-30 13:56, Cyrille Faucheux wrote:
>
>> I'm trying to learn how to properly import/export librairies with CMake.
>>
>> I think I've read somewhere that the proper way to export libraries is
>> through the module mode (as described in [1]), but:
>> a) I can't find back where I've read that,
>> b) Lots of libraries are still using the module mode (Find*.cmake).
>>
>> Can you confirm me which mode I should choose?
>>
>
> It's definitely preferred these days to work with exported/imported
> targets where possible. Unlike find modules, imported targets let you link
> to target names in consuming projects. Also, now that target usage
> requirements have arrived, you can have implicit compile flags, include
> directories, and interface link libraries for imported targets. All of this
> makes it much easier to use external libraries and lessens the distinction
> between an imported and local target.
>
> Additionally, this happens in one place. Find modules tend to end up
> copied about to different projects until/unless they wind up in CMake
> proper, and even then can linger on, resulting in multiple versions in
> varying states of bitrot. They can even be written multiple times by
> different people in unrelated projects. By providing a package config file
> (even one that just sets find module style variables) you prevent this
> proliferation and duplication of work.
>
> The flip side (and why you have a lot of find modules still) is that the
> onus to provide a package config file is on the upstream. This means that
> upstream must either build with CMake in the first place, and have the
> necessary logic in the CMake build instructions to generate a package
> config file (ideally with exported targets), or else be friendly enough to
> CMake to generate 'by hand' such a file despite using some other build
> system. It should go without saying that, especially in the latter case,
> politics can become involved here.
>
> --
> Matthew
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/**CMake_FAQ<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<http://cmake.org/cmake/help/support.html>
> CMake Consulting: http://cmake.org/cmake/help/**consulting.html<http://cmake.org/cmake/help/consulting.html>
> CMake Training Courses: http://cmake.org/cmake/help/**training.html<http://cmake.org/cmake/help/training.html>
>
> Visit other Kitware open-source projects at http://www.kitware.com/**
> opensource/opensource.html<http://www.kitware.com/opensource/opensource.html>
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/**listinfo/cmake<http://www.cmake.org/mailman/listinfo/cmake>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20131031/f155740a/attachment-0001.htm>