[CMake] find_package scoping mystery

[Andreas Pakulat]

On 16.04.12 06:04:33, Dave Abrahams wrote:
> 
> 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.

Well, thats the price to pay to keep existing CMake code still running.
Backwards compatibility is valued very high for CMake and IMHO thats a
good thing most of the time.

Andreas