<div class="gmail_quote">On Wed, Mar 4, 2009 at 11:40 AM, Michael Wild <span dir="ltr"><<a href="mailto:themiwi@gmail.com">themiwi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.</blockquote>
<div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"></div>
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.</blockquote><div><br>
"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.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"></div>
But then the namespace name becomes "part of" the function name, separating the two clearly.</blockquote><div><br>So think of the directory in which a macro is defined as "part of" the macro or function name. It's the same thing.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">I fail to see the issue.<br>
<br></div>
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...</blockquote>
<div><br>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.<br>
<br>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.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"></div>
Again, why??? Simply don't do it.<div class="im">
<br></div>
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...</blockquote><div><br>Again, this is "good enough" for <b><i>you</i></b>. 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".<br>
</div></div><br>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.<br>
<br>A lot of times I organize projects with a common directory hierarchy in groups. For example, I may have projects structured like this:<br><br>
foo/components/A<br>
foo/components/B<br>
foo/components/C<br><br>I can have the <span style="font-family: courier new,monospace;">foo/components/CMakeLists.txt</span> file define a macro called <span style="font-family: courier new,monospace;">define_component()</span>. 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 <span style="font-family: courier new,monospace;">foo/libraries</span>, for example.<br>
<br>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.<br>