[CMake] CMake: using dlopen

Franck Houssen franck.houssen at inria.fr
Mon Jan 8 05:56:47 EST 2018


----- Mail original -----

> De: "Eric Noulard" <eric.noulard at gmail.com>
> À: "Franck Houssen" <franck.houssen at inria.fr>
> Cc: "J Decker" <d3ck0r at gmail.com>, "CMake Mail List" <cmake at cmake.org>
> Envoyé: Lundi 8 Janvier 2018 11:27:29
> Objet: Re: [CMake] CMake: using dlopen

> 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.

I agree. 

> 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.

Yes ! 

> 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/1886b1f8/attachment-0001.html>


More information about the CMake mailing list