[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 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.

It doesn't have to be.  If there was a way to say "this function doesn't
create its own scope," I could create a wrapper for find_package that
doesn't interfere with its meaning.  Then I wouldn't have to pay that
price.

> Backwards compatibility is valued very high for CMake and IMHO thats a
> good thing most of the time.

No doubt about it.  

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