[CMake] Scope of a macro

[Robert Dailey]

On Wed, Mar 4, 2009 at 11:40 AM, Michael Wild <themiwi at gmail.com> wrote:

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


Is CMake not general-purpose as well? I'm not asking CMake to become C++,
however there are some common language features that are useful. Note that
there are already concepts in CMake that respect directory scope. There are
properties specific to directories, for example. Another example is
include_directories(). Include directories added by a parent are available
to children and children can append to this list, however siblings do not
inherit each others' include directories.

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.


"Good enough" is relative. Each person has their own standards for "Good
enough", so there is no one true path here that will make everyone happy.

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


So think of the directory in which a macro is defined as "part of" the macro
or function name. It's the same thing.


> I fail to see the issue.
>
> 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...


Code documentation does not prevent programmer error. It is error prone to
have macros or functions available to the parent directory in which they
were defined. What if I was going through and doing some refactoring and I
renamed a macro somewhere and also put it a bit further down in the
directory tree. Other places that call it will still work and CMake will not
give me an error message.

CMakee, like other languages, can benefit from refactoring and often times
we can miss things when we refactor. Having the language be as preemptive as
possible will help to eliminate programmer error.


> Again, why??? Simply don't do it.
> 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...


Again, this is "good enough" for *you*. Obviously not everyone will agree
with your outlook on how CMake should work, and the same goes for my opinion
on it. I also don't like the mentality most open source projects take of "If
you don't like it, implement it yourself". I've actually implemented
features that made sense in other open source projects before, only for
their authors to arrogantly refuse to apply them because of their personal
bias towards it being "good enough".

I think the best step to take in this case is to call a vote from the
community. Let's see how many people would actually like to see child macros
not available to their parent directories. I think this is a fundamental
concept shared by many languages and makes perfect logical sense.

A lot of times I organize projects with a common directory hierarchy in
groups. For example, I may have projects structured like this:

foo/components/A
foo/components/B
foo/components/C

I can have the foo/components/CMakeLists.txt file define a macro called
define_component(). This macro would take advantage of the fact that it
knows a little bit about the hierarchical pattern of the directory structure
for all component projects A, B, and C. However, this macro is completely
useless in a directory called foo/libraries, for example.

Having said that, why should the macro defined in
foo/components/CMakeLists.txt be in any way accessible in
foo/libraries/CMakeLists.txt? It is error prone and causes suble bugs in
CMake that can take a long time to track down.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090304/1fa93c4e/attachment.htm>