CMake: using dlopen

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

Franck Houssen
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" <[hidden email]>
À: "J Decker" <[hidden email]>
Cc: "Franck Houssen" <[hidden email]>, "CMake Mail List" <[hidden email]>
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:

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 <[hidden email]>:

On Mon, Jan 8, 2018 at 1:41 AM, Franck Houssen <[hidden email]> wrote:


----- Mail original -----
> De: "Rainer Poisel" <[hidden email]>
> À: "Franck Houssen" <[hidden email]>
> 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 <[hidden email]>
> 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


--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

Eric Noulard
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" :

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 <[hidden email]>:
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" <[hidden email]>
À: "J Decker" <[hidden email]>
Cc: "Franck Houssen" <[hidden email]>, "CMake Mail List" <[hidden email]>
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:

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 <[hidden email]>:

On Mon, Jan 8, 2018 at 1:41 AM, Franck Houssen <[hidden email]> wrote:


----- Mail original -----
> De: "Rainer Poisel" <[hidden email]>
> À: "Franck Houssen" <[hidden email]>
> 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 <[hidden email]>
> 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

--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

Franck Houssen



De: "Eric Noulard" <[hidden email]>
À: "Franck Houssen" <[hidden email]>
Cc: "J Decker" <[hidden email]>, "CMake Mail List" <[hidden email]>
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" :

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 <[hidden email]>:
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" <[hidden email]>
À: "J Decker" <[hidden email]>
Cc: "Franck Houssen" <[hidden email]>, "CMake Mail List" <[hidden email]>
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:

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 <[hidden email]>:

On Mon, Jan 8, 2018 at 1:41 AM, Franck Houssen <[hidden email]> wrote:


----- Mail original -----
> De: "Rainer Poisel" <[hidden email]>
> À: "Franck Houssen" <[hidden email]>
> 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 <[hidden email]>
> 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


--

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
12