[CMake] Scope of a macro

[Michael Wild]

I seriously doubt that you need the level of complexity in CMake as is  
required in a general-purpose programming language as C++. Perhaps  
Bill (or one of the other CMake developers) can shed some more light  
on this, but I think the current approach was chosen for simplicity.  
This way one does not have to keep track of scoping and introduce some  
kind of macro/function stack.
On 4. Mar, 2009, at 17:20, Robert Dailey wrote:

> In C++, you can have two functions with the same name in two different
> translation units and they can both do different things so long as  
> they are
> static.

Exactly. But then, CMake never tried to be as complete as C++, nor  
should it. It has one specific goal to which the language has been  
tailored. It kind of follows the "good enough" paradigm.

> You can also have two functions with the same name in two different
> namespaces and the implementations can also vary.

But then the namespace name becomes "part of" the function name,  
separating the two clearly.

> I fail to see the issue.
> Defining macros or functions in a deeper directory serves a useful  
> purpose
> because it provides a way of hiding macros that may be specific to  
> only that
> directory from other directories.

Why on earth do you really need that? After all, it's your code. You  
don't have to distribute your build system as a library where you have  
to hide the inner workings from users. If you intend that macro to be  
used only in one place, then DON'T call it somewhere else. Further, if  
you define a macro in foo/bar, I hardly think that any of your co- 
workers will try to use it in foo/baz. Especially if you properly  
document your code...

> I have functions available in other
> directories which should not be accessible.

Again, why??? Simply don't do it.

>
>
> Is this a bug or a feature?

Neither. It is "good enough". If you don't agree, submit a patch  
introducing scoped macro/function names. But I suspect it would break  
a lot of existing code...


Michael

>
>
> On Wed, Mar 4, 2009 at 1:43 AM, Michael Wild <themiwi at gmail.com>  
> wrote:
>
>>
>> On 4. Mar, 2009, at 7:11, Robert Dailey wrote:
>>
>> On Wed, Mar 4, 2009 at 12:02 AM, Michael Wild <themiwi at gmail.com>  
>> wrote:
>>>
>>> If you add a subdirectory, it inherits all variables and macros  
>>> from the
>>>> parent directories. This is actually what one expects, otherwise  
>>>> you
>>>> would
>>>> have to repeat the whole system detection (find_pacakge,  
>>>> find_library,
>>>> find_path etc.) in every subdirectory. The reverse, however is  
>>>> not true.
>>>> By
>>>> default, variables (I'm not sure about macros) don't propagate  
>>>> into the
>>>> parent scope, unless one uses the PARENT_SCOPE option or adds the
>>>> variable
>>>> to the cache which makes it global.
>>>>
>>>
>>>
>>> That makes perfect sense and works as I would expect. However, I'm  
>>> seeing
>>> the behavior you state should not happen. That is, the macros  
>>> defined in
>>> the
>>> child directory are somehow propagating up to the parent.
>>>
>>
>> Sorry, must have missed the bar/baz difference... Well, I figure it  
>> also
>> makes some sense that macros and functions are global. Otherwise  
>> one would
>> have very confusing things going on, like a macro by the same name  
>> doing
>> completely unrelated things in different directories.
>>
>> Michael
>>