[CMake] CMake: using dlopen

[J Decker]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180108/bd115b35/attachment.html>