[CMake] find_package scoping mystery

[Dave Abrahams]

on Mon Apr 16 2012, Andreas Pakulat <apaku-Mmb7MZpHnFY-AT-public.gmane.org> wrote:

> On 16.04.12 01:37:58, Dave Abrahams wrote:
>> 
>> consider this simple wrapper:
>> 
>>   function(my_find_package)
>>     find_package(${ARGV})
>
>>   endfunction()
>> 
>> If I replace all the calls to find_package in my project with calls to
>> my_find_package, everything breaks.  It appears variable settings in any
>> found <packagename>Config.cmake files are visible inside
>> my_find_package, but disappear from the point of view of the caller,
>> unless I "manually" hoist them into the parent scope using
>> 
>>   function(my_find_package)
>>     find_package(${ARGV})
>>     set(some_variable ${some_variable} PARENT_SCOPE)
>>   endfunction()
>> 
>> I've tried hoisting everything as in
>> https://github.com/ryppl/ryppl-cmake/blob/find-package-hook/Modules/Ryppl.cmake#L9,
>> but apparently that is too much and it clobbers some variables that it
>> shouldn't.
>> 
>> Can anyone explain to me what I'm failing to grasp, here?
>
> Functions have their own scope and the find module are written to be
> executed in the global scope. (functions are still a relatively new
> feature in cmake)

That's one way of saying it.  The other way of saying it is that
built-in functions are special and can't be emulated or wrapped if they
end up include()ing anything.  The built-ins don't create a dynamic
scope, so set() commands in files they include end up having an effect
at global scope.  The other other way of saying it is @#&(!&!%%*!... but
I digress.

>
> I can see a few options:
> - Don't run find_package inside a function.
> - Use a macro instead of a function, macro's do not create a new scope

Yeah... these are two ways of saying the same thing.  I ended up with a
macro.

> - inspect all the find-modules you use and adapt them to use
>   PARENT_SCOPE for variables when they do not end up in the cache.


Thanks for your help,

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com