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 <[email protected]>
wrote:
On 4. Mar, 2009, at 7:11, Robert Dailey wrote:
On Wed, Mar 4, 2009 at 12:02 AM, Michael Wild <[email protected]>
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
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
