# find\_package inside function: scope issue

**URL:** <https://discourse.cmake.org/t/find-package-inside-function-scope-issue/15362>\
**Category:** Code\
**Created:** [December 4, 2025, 4:02pm UTC](https://discourse.cmake.org/t/find-package-inside-function-scope-issue/15362 "2025-12-04T16:02:29Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![adaldev](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/a/9dc877/32.png) [@adaldev](https://discourse.cmake.org/u/adaldev)\
**Post date:** [December 4, 2025, 4:02pm UTC](https://discourse.cmake.org/t/find-package-inside-function-scope-issue/15362/1 "2025-12-04T16:02:29Z")

</div>

Hi,

I’m wrapping some calls to find\_package inside functions. The issue is that the variables set by find\_package are not visible to the parent scope and I don’t know the list of this variables (so I cannot use `set` with `PARENT_SCOPE` option.

It would be difficult for me to convert the function to a macro as I’ve got some `return()` statements.

How can I do to forward these variables to the parent scope?

Regards,  
A.

---

<div class="post-metadata">

**Author:** ![Andrej730](https://discourse.cmake.org/user_avatar/discourse.cmake.org/andrej730/32/5752_2.png) [@Andrej730](https://discourse.cmake.org/u/Andrej730)\
**Post date:** [December 4, 2025, 5:08pm UTC](https://discourse.cmake.org/t/find-package-inside-function-scope-issue/15362/2 "2025-12-04T17:08:40Z")

</div>

From what I know, `find_package` call essentially works like `include` - so it’s just adds code to the current scope and executes it. So basically the question is how to propagate function variable to parent scope without specifying it explicitly.  
Unfortunately, I don’t think there’s a way to do it, besides using a macro and making code more nested to remove the need for `return()` statements.

---

<div class="post-metadata">

**Author:** ![Angew](https://discourse.cmake.org/user_avatar/discourse.cmake.org/angew/32/229_2.png) [@Angew](https://discourse.cmake.org/u/Angew)\
**Post date:** [December 4, 2025, 6:55pm UTC](https://discourse.cmake.org/t/find-package-inside-function-scope-issue/15362/3 "2025-12-04T18:55:25Z")

</div>

There is a hack for avoiding `return()` in macros: if none of your `return()` statements is nested inside a loop, you can add an outermost one-iteration loop around the entire code of the macro, and then use `break()` with the same effect as `return()` from a function would have. Example:

```auto
function(foo)
  do_stuff()
  if(${stopEarly})
    return()
  endif()
  do_more()
endfunction()

# Can become:

macro(foo)
  foreach(dummy IN ITEMS 1)
    do_stuff()
    if(${stopEarly})
      break()
    endif()
    do_more()
  endforeach()
endmacro()

```

If you decide to go this route, I suggest document it well.

---

<div class="post-metadata">

**Author:** ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)\
**Post date:** [December 4, 2025, 9:02pm UTC](https://discourse.cmake.org/t/find-package-inside-function-scope-issue/15362/4 "2025-12-04T21:02:06Z")

</div>

Not quite what you asked, but I recommend that ideally you should not use any variables a package might define, relying instead only on the targets and commands it defines. Commands are global, and targets created by `find_package()` are visible at least in the current _directory_ scope and below (they might also be global depending on whether the `GLOBAL` keyword was given or the `CMAKE_FIND_PACKAGE_TARGETS_GLOBAL` variable is set to true).

If you follow the above recommendation, then your project likely won’t care whether the `find_package()` call was made inside a function or other variable scope (like `block()` / `end block()`). I say “likely won’t care” because a package might define a non-cache variable outside of a function, expecting that variable to be available to that function’s implementation. But since functions are global, they could be called from any scope, including scopes where that variable isn’t visible. I consider such variables to be a bug in the package.