[CMake] Scope of a macro

Robert Dailey rcdailey at gmail.com
Wed Mar 4 11:20:36 EST 2009


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. You can also have two functions with the same name in two different
namespaces and the implementations can also vary. 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. I have functions available in other
directories which should not be accessible.

Is this a bug or a feature?

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090304/b4edb7fa/attachment-0001.htm>


More information about the CMake mailing list