# find\_package on system libcurl does not set the target to global
**URL:** https://discourse.cmake.org/t/find-package-on-system-libcurl-does-not-set-the-target-to-global/13695
**Category:** Usage
**Created:** [March 7, 2025, 3:23pm UTC](https://discourse.cmake.org/t/find-package-on-system-libcurl-does-not-set-the-target-to-global/13695 "2025-03-07T15:23:08Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@boxerab](https://discourse.cmake.org/u/boxerab)
#### Post date: [March 7, 2025, 3:23pm UTC](https://discourse.cmake.org/t/find-package-on-system-libcurl-does-not-set-the-target-to-global/13695/1 "2025-03-07T15:23:08Z")
Hello There,
I recently added `libcurl` support to my project, and I found that if fetching and building `liburl` from git, the `CURL::libcurl` target is global and can be used in subfolder cmake files. But, when running `find_package` on system `libcurl`, `CURL::libcurl` is not global,and I have to manually set it to be global.
Not sure who is responsible for libcurl find\_package, so posting it here.
Thanks!!
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [March 9, 2025, 10:33pm UTC](https://discourse.cmake.org/t/find-package-on-system-libcurl-does-not-set-the-target-to-global/13695/2 "2025-03-09T22:33:59Z")
By default, imported targets created by `find_package()` will be non-global. There are reasons for that related to allowing different packages to be found for the same dependency for calls to `find_package()` in unrelated directory scopes. Personally, I strongly advise people to avoid that, since it is rarely what folks expect or want these days. You are likely only going to want one version of a dependency to be used consistently across your whole project. I wish that was the default behavior, but historically it isn’t.
The easiest way to make all your `find_package()` calls create global imported targets is to set the [CMAKE\_FIND\_PACKAGE\_TARGETS\_GLOBAL](https://cmake.org/cmake/help/latest/variable/CMAKE_FIND_PACKAGE_TARGETS_GLOBAL.html) CMake variable to true at the top level of your project, ideally soon after the first call to `project()`. Keep in mind that doing so will force that choice on other projects that might consume yours via FetchContent or as a git submodule, but in some situations (like controlled company environments), it can be appropriate.
---
### Author:  [@boxerab](https://discourse.cmake.org/u/boxerab)
#### Post date: [March 11, 2025, 2:21pm UTC](https://discourse.cmake.org/t/find-package-on-system-libcurl-does-not-set-the-target-to-global/13695/3 "2025-03-11T14:21:19Z")
@craig.scott thanks! I agree, I can’t see why anyone would want multiple packages for a single dependency. My follow up question is : why does building from git behave differently than `find_package()` ?
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [March 11, 2025, 9:02pm UTC](https://discourse.cmake.org/t/find-package-on-system-libcurl-does-not-set-the-target-to-global/13695/4 "2025-03-11T21:02:37Z")
When building from source, all build system targets are global. When you bring something in via `find_package()`, you’re not building it (well, you can be these days with things like the `find_package()` and FetchContent integration, but that’s a relatively recent feature). Building versus importing are completely different operations. There’s not even any requirement that they produce the same things, although a well-behaved project should provide the same set of documented targets.
You’re getting into the territory of “what goes into a package”, which is a very different question to “how do I build this, and what does the build produce”.