<div class="gmail_quote">On Mon, Apr 16, 2012 at 9:21 AM, Dave Abrahams <span dir="ltr"><<a href="mailto:dave@boostpro.com">dave@boostpro.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
on Mon Apr 16 2012, Andreas Pakulat <<a href="http://apaku-Mmb7MZpHnFY-AT-public.gmane.org" target="_blank">apaku-Mmb7MZpHnFY-AT-public.gmane.org</a>> wrote:<br>
<br>
> On 16.04.12 06:04:33, Dave Abrahams wrote:<br>
>><br>
>> on Mon Apr 16 2012, Andreas Pakulat <<a href="http://apaku-Mmb7MZpHnFY-AT-public.gmane.org" target="_blank">apaku-Mmb7MZpHnFY-AT-public.gmane.org</a>> wrote:<br>
>><br>
>> > On 16.04.12 01:37:58, Dave Abrahams wrote:<br>
>> >><br>
><br>
>> >> consider this simple wrapper:<br>
>> >><br>
>> >> function(my_find_package)<br>
>> >> find_package(${ARGV})<br>
>> ><br>
>> >> endfunction()<br>
>> >><br>
>> >> If I replace all the calls to find_package in my project with calls to<br>
>> >> my_find_package, everything breaks. It appears variable settings in any<br>
>> >> found <packagename>Config.cmake files are visible inside<br>
>> >> my_find_package, but disappear from the point of view of the caller,<br>
>> >> unless I "manually" hoist them into the parent scope using<br>
>> >><br>
>> >> function(my_find_package)<br>
>> >> find_package(${ARGV})<br>
>> >> set(some_variable ${some_variable} PARENT_SCOPE)<br>
>> >> endfunction()<br>
>> >><br>
>> >> I've tried hoisting everything as in<br>
>> >> <a href="https://github.com/ryppl/ryppl-cmake/blob/find-package-hook/Modules/Ryppl.cmake#L9" target="_blank">https://github.com/ryppl/ryppl-cmake/blob/find-package-hook/Modules/Ryppl.cmake#L9</a>,<br>
>> >> but apparently that is too much and it clobbers some variables that it<br>
>> >> shouldn't.<br>
>> >><br>
>> >> Can anyone explain to me what I'm failing to grasp, here?<br>
>> ><br>
>> > Functions have their own scope and the find module are written to be<br>
>> > executed in the global scope. (functions are still a relatively new<br>
>> > feature in cmake)<br>
>><br>
>> That's one way of saying it. The other way of saying it is that<br>
>> built-in functions are special and can't be emulated or wrapped if they<br>
>> end up include()ing anything. The built-ins don't create a dynamic<br>
>> scope, so set() commands in files they include end up having an effect<br>
>> at global scope. The other other way of saying it is @#&(!&!%%*!... but<br>
>> I digress.<br>
><br>
> Well, thats the price to pay to keep existing CMake code still<br>
> running.<br>
<br>
</div></div>It doesn't have to be. If there was a way to say "this function doesn't<br>
create its own scope," I could create a wrapper for find_package that<br>
doesn't interfere with its meaning. Then I wouldn't have to pay that<br>
price.<br>
<div class="im"><br>
> Backwards compatibility is valued very high for CMake and IMHO thats a<br>
> good thing most of the time.<br>
<br>
</div>No doubt about it.<br>
<div class="im HOEnZb"><br></div></blockquote><div><br></div><div><br></div><div>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.</div>
<div><br></div><div>So just use a "macro" and all is well in this case, isn't it?</div><div><br></div><div>Is there a problem with using a macro here?</div><div><br></div></div>