[CMake] CMake: using dlopen

Eric Noulard eric.noulard at gmail.com
Mon Jan 8 05:27:29 EST 2018


Franck,

Yes I understand and I mostly do the same.

However, anyone who already faced similar issue should be able to point you
to the "right" place in the doc.
Since this kind of discussion is popping up again I guess  the doc still
miss some bits.

I think the right place would be "usage requirements" :
https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html#target-usage-requirements

It could be improved for better understanding the impact of
PUBLIC/PRIVATE/INTERFACE
may be with some examples.


2018-01-08 11:07 GMT+01:00 Franck Houssen <franck.houssen at inria.fr>:

> I usually read the doc in a step-by-step mode (going from "small things"
> to "the next") when a (new) need/question shows up. When I can I try to
> "push" some notions (this is an example of it !).
> The doc is "vast" which is a good thing but not so easy when trying to
> read/understand all of it (personal opinion). To me, the doc misses simple
> illustrative examples like Rainer's one (here again, personal opinion).
>
>
> ------------------------------
>
> *De: *"Eric Noulard" <eric.noulard at gmail.com>
> *À: *"J Decker" <d3ck0r at gmail.com>
> *Cc: *"Franck Houssen" <franck.houssen at inria.fr>, "CMake Mail List" <
> cmake at cmake.org>
> *Envoyé: *Lundi 8 Janvier 2018 10:53:51
>
> *Objet: *Re: [CMake] CMake: using dlopen
>
> Explanations on PRIVATE, PUBLIC, INTERFACE has already been discussed in
> those ML threads:
> https://cmake.org/pipermail/cmake/2017-April/065340.html
> https://cmake.org/pipermail/cmake/2016-May/063400.html
>
> I guess we need some doc update.
> I did promess contribution and I didn't do it.
> I'll try again.
>
>
> 2018-01-08 10:45 GMT+01:00 J Decker <d3ck0r at gmail.com>:
>
>>
>> On Mon, Jan 8, 2018 at 1:41 AM, Franck Houssen <franck.houssen at inria.fr>
>> wrote:
>>
>>>
>>>
>>> ----- Mail original -----
>>> > De: "Rainer Poisel" <rainer.poisel at gmail.com>
>>> > À: "Franck Houssen" <franck.houssen at inria.fr>
>>> > Envoyé: Dimanche 7 Janvier 2018 19:34:21
>>> > Objet: Re: [CMake] CMake: using dlopen
>>> >
>>> > Hi,
>>> >
>>> > On Sun, Jan 7, 2018 at 7:13 PM, Franck Houssen <
>>> franck.houssen at inria.fr>
>>> > wrote:
>>> > > Difference between PUBLIC/PRIVATE has never been clear to me
>>> (usually I
>>> > > always use PUBLIC).
>>> > > main.cpp includes dlfcn.h and uses it: not sure to get what you meant
>>> > > (PRIVATE is for templates ? when a header include headers ?)
>>> >
>>> > you are looking for the "Transitive Dependencies" feature of CMake:
>>>
>>> OK, I didn't get that. It's more clear to me now. Thanks !
>>>
>>> >   *
>>> >   https://cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.
>>> 7.html#transitive-usage-requirements
>>> >
>>> > Generally speaking and from my personal experience, use the
>>> > target_-commands as much as possible because properties are bound to
>>> > targets and their dependencies rather than a file/directory structure.
>>> >
>>> > So, that means, use target_include_directories(),
>>> > target_compile_options(), target_compile_definitions(),
>>> > target_sources(), ... for your targets. The magic keyword to propagate
>>> > the properties of your targets is target_link_libraries(). Depending
>>> > on what scope (PRIVATE, PUBLIC, INTERFACE) the properties have been
>>> > defined using the other target_-commands, the target_link_libraries()
>>> > command propagates these properties to other targets. E. g.
>>> >
>>> > add_library(otherlib SHARED
>>> >   foo.c
>>> > )
>>> >
>>> > target_include_directories(otherlib PRIVATE
>>> >   dirPrivate
>>> > )
>>> >
>>> > target_include_directories(otherlib PUBLIC
>>> >   dirPublic
>>> > )
>>> >
>>> > add_library(mylib SHARED
>>> >   bar.c
>>> > )
>>> >
>>> > target_link_libraries(mylib PRIVATE
>>>
>>> Is this a typo ?
>>> For the example to work I would have done: target_link_libraries(mylib
>>> PUBLIC otherLib), no ? (mylib needs only PUBLIC stuff's from otherLib but
>>> not PRIVATE one's). Correct ?
>>>
>>>
>> Public is whether it propagates outside of the current target to things
>> that then require 'mylib'
>> private keeps it within that target, has nothing to do with what it's
>> pulling from any linked library.
>>
>>
>>>
>>> >   otherlib
>>> > )
>>> >
>>> > In this case, mylib will use all PUBLIC or INTERFACE properties of
>>> > otherlib for its build. Thus, dirPublic will be added to the include
>>> > directory search path for the compilation of bar.c of mylib. PRIVATE
>>> > properties will not be propagated. In the above mentioned example,
>>> > dirPrivate will NOT be added to the include directory search path for
>>> > the compilation of bar.c of mylib.
>>> >
>>>
>>> The example is illustrative (transitivity - PRIVATE is not propagated)
>>>
>>> > This is a very short summary, but I hope it is of help to you. There
>>> > are other ressources on the Internet. E. g.
>>> >   *
>>> >   https://stackoverflow.com/questions/26037954/cmake-
>>> target-link-libraries-interface-dependencies
>>> >   * https://rix0r.nl/blog/2015/08/13/cmake-guide/
>>> >
>>> > Regards,
>>> >   Rainer
>>> >
>>> --
>>>
>>> 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:
>>> https://cmake.org/mailman/listinfo/cmake
>>>
>>
>>
>> --
>>
>> 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:
>> https://cmake.org/mailman/listinfo/cmake
>>
>>
>
>
> --
> Eric
>
>
>


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180108/599845e4/attachment.html>


More information about the CMake mailing list