[CMake] find_package scoping mystery

[David Cole]

On Mon, Apr 16, 2012 at 9:21 AM, Dave Abrahams <dave at boostpro.com> wrote:

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

But that's the main difference between "macro" and "function" -- we
invented function to give scope because there were no end of complaints
about macros not having scope, and endless pollution of the global name
space with more and more variables.

So just use a "macro" and all is well in this case, isn't it?

Is there a problem with using a macro here?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20120416/53268964/attachment.htm>