Re: [CMake] How does :: actually works?
On 17 June 2015 at 22:58, Stephen Kelly steve...@gmail.com wrote: Klaim - Joël Lamotte wrote: Thinking about boost, if package files works well with header-only libraries (which I suppose it should as long as the boost define header-only targets) then it would be very useful indeed. Yes, I wrote some cmake 3.0 features specifically for the Boost use cases (header only and lots of cyclic dependencies). Then I have to have all my libraries to link with all the boost libraries listed in the boost library variable generated by FindBoost. I don't have working knowledge of FindBoost, so I can't give a good answer. The documentation at the top of the file says it creates a variable per library though. Yes it seems that I missed that part when I worked on it, totally my mistake. If I understand correctly, if FindBoost was supporting imported targets and using Boost as a namespace (like Qt does), then I could link my libraries to boost libraries in a more precise way as I would link each library separately instead of everything FindBoost put in the boost libraries variable. This still has other advantages anyway, such as transitivity, conciseness, consistency, better error messages etc. Thanks, Steve. -- 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: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How does :: actually works?
Klaim - Joël Lamotte wrote: I didn't realize at all that the FindPackage way is supposed to be obsolete now. It is not obsolete, but it is not a good approach (since CMake 2.6.0 already) if the upstream uses cmake, because config file packages provide a better experience for downstreams http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html Even for upstreams that do not use cmake, it is preferable to generate config file packages for a good downstream experience for cmake users. That is what Qt qmake and LLVM Makefile buildsystems do. Boost b2 could do it too: http://thread.gmane.org/gmane.comp.lib.boost.devel/259011/focus=259445 I'm quite surprised actually. We prefer not to accept new Find modules into the cmake tree because that puts the maintenance burden on us, and because it is an inferior user experience. Some new Find modules still get in, but they need to have a reason to get in. Ok I'll check PackageConfig.cmake for my new and even current projects if it can help with managing the tons of libraries I work on. Do please let us know how that goes. I will consider providing patches, if I can spend time on this once and not bother later it would help a lot. Documentation here explains how to do that for Find modules: http://www.cmake.org/cmake/help/v3.2/manual/cmake-developer.7.html#a-sample-find-module Thanks, Steve. -- 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: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How does :: actually works?
On 17 June 2015 at 20:50, Stephen Kelly steve...@gmail.com wrote: Klaim - Joël Lamotte wrote: I didn't realize at all that the FindPackage way is supposed to be obsolete now. It is not obsolete, but it is not a good approach (since CMake 2.6.0 already) if the upstream uses cmake, because config file packages provide a better experience for downstreams http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html Even for upstreams that do not use cmake, it is preferable to generate config file packages for a good downstream experience for cmake users. That is what Qt qmake and LLVM Makefile buildsystems do. Boost b2 could do it too: http://thread.gmane.org/gmane.comp.lib.boost.devel/259011/focus=259445 I remember the discussion but did not realize that it was a tool supposed to be useful for any project. Thinking about boost, if package files works well with header-only libraries (which I suppose it should as long as the boost define header-only targets) then it would be very useful indeed. By the way, in one of my project I end up using one FindBoost call with all the components needed by all the libraries of the project. I do this to avoid having to call FindBoost separately for every library with different components (still using the COMPONENTS option listing what the whole project needs). Then I have to have all my libraries to link with all the boost libraries listed in the boost library variable generated by FindBoost. If I understand correctly, if FindBoost was supporting imported targets and using Boost as a namespace (like Qt does), then I could link my libraries to boost libraries in a more precise way as I would link each library separately instead of everything FindBoost put in the boost libraries variable. Is my understanding correct? I'm quite surprised actually. We prefer not to accept new Find modules into the cmake tree because that puts the maintenance burden on us, and because it is an inferior user experience. Some new Find modules still get in, but they need to have a reason to get in. Ok I'll check PackageConfig.cmake for my new and even current projects if it can help with managing the tons of libraries I work on. Do please let us know how that goes. I will. I will consider providing patches, if I can spend time on this once and not bother later it would help a lot. Documentation here explains how to do that for Find modules: http://www.cmake.org/cmake/help/v3.2/manual/cmake-developer.7.html#a-sample-find-module Thanks, Thanks for the pointer. Steve. -- 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: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How does :: actually works?
Klaim - Joël Lamotte wrote: Thinking about boost, if package files works well with header-only libraries (which I suppose it should as long as the boost define header-only targets) then it would be very useful indeed. Yes, I wrote some cmake 3.0 features specifically for the Boost use cases (header only and lots of cyclic dependencies). Then I have to have all my libraries to link with all the boost libraries listed in the boost library variable generated by FindBoost. I don't have working knowledge of FindBoost, so I can't give a good answer. The documentation at the top of the file says it creates a variable per library though. If I understand correctly, if FindBoost was supporting imported targets and using Boost as a namespace (like Qt does), then I could link my libraries to boost libraries in a more precise way as I would link each library separately instead of everything FindBoost put in the boost libraries variable. This still has other advantages anyway, such as transitivity, conciseness, consistency, better error messages etc. Thanks, Steve. -- 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: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How does :: actually works?
On 16 June 2015 at 11:49, Johannes Zarl-Zierl johannes.zarl-zi...@jku.at wrote: On Monday 15 June 2015 22:43:41 you wrote: Just a last question: I assume that most find module scripts distributed with cmake are not using this feature at the moment, right? Sadly, no. After reading your explaination I looked at documentation for FindBoost and FindGTest which are both used in all my projects and they dont seem to provide import targets. Are there plans to update the cmake scripts distributed with CMake On the one hand, FindPackage modules are, as far as I'm aware, slowly being updated to use imported targets. On the other hand, quite a few packages are missing a maintainer[1]. If you are using a package and want it to provide imported targets, I think your best bet is to propose a patch for the module and get it into cmake. That said, its worth mentioning that FindPackage modules are only intended for legacy projects which do not provide a PackageConfig.cmake file. If you are writing a new project, especially if it's based on cmake, you should write a PackageConfig.cmake file instead [2]. I didn't realize at all that the FindPackage way is supposed to be obsolete now. I'm quite surprised actually. Ok I'll check PackageConfig.cmake for my new and even current projects if it can help with managing the tons of libraries I work on. or is it just assumed that projects willing to use importing targets will write them somewhere before using them? Creating imported targets on your own is not the way to go. Better file a bug report or write a patch to add the functionality and get that into cmake. IMO, until the official module provides imported targets, you're better off using the old way. I will consider providing patches, if I can spend time on this once and not bother later it would help a lot. Thanks again for these explainations. Cheers, Johannes [1] http://www.cmake.org/Wiki/CMake:Module_Maintainers#List [2] http://www.cmake.org/Wiki/CMake/Tutorials#CMake_Packages -- 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: http://public.kitware.com/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: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How does :: actually works?
On Monday 15 June 2015 22:43:41 you wrote: Just a last question: I assume that most find module scripts distributed with cmake are not using this feature at the moment, right? Sadly, no. After reading your explaination I looked at documentation for FindBoost and FindGTest which are both used in all my projects and they dont seem to provide import targets. Are there plans to update the cmake scripts distributed with CMake On the one hand, FindPackage modules are, as far as I'm aware, slowly being updated to use imported targets. On the other hand, quite a few packages are missing a maintainer[1]. If you are using a package and want it to provide imported targets, I think your best bet is to propose a patch for the module and get it into cmake. That said, its worth mentioning that FindPackage modules are only intended for legacy projects which do not provide a PackageConfig.cmake file. If you are writing a new project, especially if it's based on cmake, you should write a PackageConfig.cmake file instead [2]. or is it just assumed that projects willing to use importing targets will write them somewhere before using them? Creating imported targets on your own is not the way to go. Better file a bug report or write a patch to add the functionality and get that into cmake. IMO, until the official module provides imported targets, you're better off using the old way. Cheers, Johannes [1] http://www.cmake.org/Wiki/CMake:Module_Maintainers#List [2] http://www.cmake.org/Wiki/CMake/Tutorials#CMake_Packages -- 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: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How does :: actually works?
On 13 June 2015 at 22:29, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Thursday, June 11, 2015 19:18:55 Klaim - Joël Lamotte wrote: On 11 June 2015 at 15:22, Johannes Zarl-Zierl johannes.zarl-zi...@jku.at wrote: Hi, I tried several times now to find documentation about how to define and use target names which seem to have namespaces, like Qt ones. For example: add_executable( MyProject::some_target ... ) AFAIK target namespaces are intended for imported targets, not regular targets: A NAMESPACE with double-colons is specified when exporting the targets for installation. This convention of double-colons gives CMake a hint that the name is an IMPORTED target when it is used by downstreams with the target_link_libraries() command. This way, CMake can issue a diagnostic if the package providing it has not yet been found. [1] [1] http://www.cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html?highligh t=namespace I can't find any documentation or even name for this. Is it considered a namespace? In any way I found nothing specific to this syntax in the wiki. The concept is called namespace in cmake, just as you assumed. I don't know if there's anything about it in the wiki, but the official documentation has a (very) short description in the cmake_packages[1] page, as well as in the documentation for the export command. (sorry I was actually thinking about the documentation and typed wiki) Thanks, it was not totally clear that the definition of the namespace is done in another operation, so I assumed that it was just a local option, not ana actual language feature, and simply dismissed it. Maybe the concept should have it's own section? There is no mention of this in the language page. Or is it really useful only if you are writing exports? Anyway thanks, it's clearer now. What do you actually want to do with the namespace ? cmake does not really have namespaces, what the documentation talks about is only used as a hint when using imported targets. Alex I'm trying to figure out better ways to organize my projects which have the following properties: 1. cross-platform (that part is covered by cmake) 2. are composed of a lot of different executables and libraries 3. have a lot of different dependencies. I also study the recent wave of dependency managements solutions, but that's another topic. One of my projects is open source and is a big set of tools (mostly libraries uses by one big gui tool) and I was wondering about the syntax that you can see in some projects like Qt, which have lot of tools too, so maybe it could be useful to me. So far I didn't get what imported targets helps with, so I'm a bit lost on the usefulness of namespaces but I am sure that I am missing something. -- 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: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How does :: actually works?
On Monday 15 June 2015 16:40:10 Klaim - Joël Lamotte wrote:
So far I didn't get what imported targets helps with, so I'm a bit lost on
the usefulness of namespaces
but I am sure that I am missing something.
Imported targets improve the handling of find_package stuff. In the old days,
the common pattern for using another library as dependency was as follows:
find_package(XXX)
include_directories( ${XXX_INCLUDE_DIR} )
add_definitions( ${XXX_DEFINITIONS} )
target_link_library(YourTarget ${XXX_LIBRARIES} )
Sometimes you don't need the add_definitions part, and sometimes the variable
names are a little bit different. Most of the time you inadvertedly add
definitions and include directories for other targets, too.
With imported targets, you can combine everything that's needed to use a
library into an imported target, making the above pattern simpler and less
error-prone:
find_package(XXX)
target_link_library(YourTarget XXX)
With more complex libraries, you often have different components, and that's
when namespaces come in handy:
find_package(XXX COMPONENTS Base Advanced)
target_link_library(YourTarget XXX::Base)
Find_package(YYY COMPONENTS Base)
target_link_library(YourOtherTarget XXX::Advanced YYY::Base)
Does this answer your question?
Cheers,
Johannes
--
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:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How does :: actually works?
On 15 June 2015 at 18:20, Johannes Zarl-Zierl johannes.zarl-zi...@jku.at
wrote:
On Monday 15 June 2015 16:40:10 Klaim - Joël Lamotte wrote:
So far I didn't get what imported targets helps with, so I'm a bit lost
on
the usefulness of namespaces
but I am sure that I am missing something.
Imported targets improve the handling of find_package stuff. In the old
days,
the common pattern for using another library as dependency was as follows:
find_package(XXX)
include_directories( ${XXX_INCLUDE_DIR} )
add_definitions( ${XXX_DEFINITIONS} )
target_link_library(YourTarget ${XXX_LIBRARIES} )
Sometimes you don't need the add_definitions part, and sometimes the
variable
names are a little bit different. Most of the time you inadvertedly add
definitions and include directories for other targets, too.
With imported targets, you can combine everything that's needed to use a
library into an imported target, making the above pattern simpler and less
error-prone:
find_package(XXX)
target_link_library(YourTarget XXX)
With more complex libraries, you often have different components, and
that's
when namespaces come in handy:
find_package(XXX COMPONENTS Base Advanced)
target_link_library(YourTarget XXX::Base)
Find_package(YYY COMPONENTS Base)
target_link_library(YourOtherTarget XXX::Advanced YYY::Base)
Does this answer your question?
Cheers,
Johannes
Yes! Thanks a lot!
I was only getting half of the usage but now it's clear.
It's pretty close to how I was working before but I was hacking stuffs in a
hard to update way.
I'll try this way of doing in one project, it seems to fix at least one
issue I have with my dependencies:
help with uprading them.
Thanks again!
Just a last question: I assume that most find module scripts distributed
with cmake are
not using this feature at the moment, right?
After reading your explaination I looked at documentation for FindBoost and
FindGTest
which are both used in all my projects and they dont seem to provide import
targets.
Are there plans to update the cmake scripts distributed with CMake
or is it just assumed that projects willing to use importing targets will
write them somewhere before using them?
--
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:
http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How does :: actually works?
On Thursday, June 11, 2015 19:18:55 Klaim - Joël Lamotte wrote: On 11 June 2015 at 15:22, Johannes Zarl-Zierl johannes.zarl-zi...@jku.at wrote: Hi, I tried several times now to find documentation about how to define and use target names which seem to have namespaces, like Qt ones. For example: add_executable( MyProject::some_target ... ) AFAIK target namespaces are intended for imported targets, not regular targets: A NAMESPACE with double-colons is specified when exporting the targets for installation. This convention of double-colons gives CMake a hint that the name is an IMPORTED target when it is used by downstreams with the target_link_libraries() command. This way, CMake can issue a diagnostic if the package providing it has not yet been found. [1] [1] http://www.cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html?highligh t=namespace I can't find any documentation or even name for this. Is it considered a namespace? In any way I found nothing specific to this syntax in the wiki. The concept is called namespace in cmake, just as you assumed. I don't know if there's anything about it in the wiki, but the official documentation has a (very) short description in the cmake_packages[1] page, as well as in the documentation for the export command. (sorry I was actually thinking about the documentation and typed wiki) Thanks, it was not totally clear that the definition of the namespace is done in another operation, so I assumed that it was just a local option, not ana actual language feature, and simply dismissed it. Maybe the concept should have it's own section? There is no mention of this in the language page. Or is it really useful only if you are writing exports? Anyway thanks, it's clearer now. What do you actually want to do with the namespace ? cmake does not really have namespaces, what the documentation talks about is only used as a hint when using imported targets. Alex -- 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: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How does :: actually works?
On 11 June 2015 at 15:22, Johannes Zarl-Zierl johannes.zarl-zi...@jku.at wrote: Hi, I tried several times now to find documentation about how to define and use target names which seem to have namespaces, like Qt ones. For example: add_executable( MyProject::some_target ... ) AFAIK target namespaces are intended for imported targets, not regular targets: A NAMESPACE with double-colons is specified when exporting the targets for installation. This convention of double-colons gives CMake a hint that the name is an IMPORTED target when it is used by downstreams with the target_link_libraries() command. This way, CMake can issue a diagnostic if the package providing it has not yet been found. [1] [1] http://www.cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html?highlight=namespace I can't find any documentation or even name for this. Is it considered a namespace? In any way I found nothing specific to this syntax in the wiki. The concept is called namespace in cmake, just as you assumed. I don't know if there's anything about it in the wiki, but the official documentation has a (very) short description in the cmake_packages[1] page, as well as in the documentation for the export command. (sorry I was actually thinking about the documentation and typed wiki) Thanks, it was not totally clear that the definition of the namespace is done in another operation, so I assumed that it was just a local option, not ana actual language feature, and simply dismissed it. Maybe the concept should have it's own section? There is no mention of this in the language page. Or is it really useful only if you are writing exports? Anyway thanks, it's clearer now. Cheers, Johannes -- 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: http://public.kitware.com/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: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How does :: actually works?
Hi, I tried several times now to find documentation about how to define and use target names which seem to have namespaces, like Qt ones. For example: add_executable( MyProject::some_target ... ) AFAIK target namespaces are intended for imported targets, not regular targets: A NAMESPACE with double-colons is specified when exporting the targets for installation. This convention of double-colons gives CMake a hint that the name is an IMPORTED target when it is used by downstreams with the target_link_libraries() command. This way, CMake can issue a diagnostic if the package providing it has not yet been found. [1] [1] http://www.cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html?highlight=namespace I can't find any documentation or even name for this. Is it considered a namespace? In any way I found nothing specific to this syntax in the wiki. The concept is called namespace in cmake, just as you assumed. I don't know if there's anything about it in the wiki, but the official documentation has a (very) short description in the cmake_packages[1] page, as well as in the documentation for the export command. Cheers, Johannes -- 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: http://public.kitware.com/mailman/listinfo/cmake
