On Mon, Aug 15, 2011 at 3:26 PM, David Cole <span dir="ltr"><<a href="mailto:david.cole@kitware.com">david.cole@kitware.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
documentation to clarify the existing situation, but I don't see a<br>
reasonable way to accommodate this feature request *and* maintain<br>
backwards compatibility with existing real world uses of macro and if<br></blockquote><div><br></div><div>Umm... once again, doesn't this case look perfect for using a policy?</div><div><br></div><div>If cmake knew the difference between identifiers and strings (foo vs. "bar"), I wouldn't mind having IF recognize foo as a variable - and only a variable (if undefined, it shouldn't be treated as "foo") - and "bar" (or "${HAVE_${foo}}") as a string, and behave accordingly.</div>
<div><br></div><div>Otherwise, IF(var) instead of IF(${var}) isn't much of a benefit to me, given the drawbacks. The unpredictable and inconsistent treatment of its arguments by IF() is something I'd consider a major drawback.</div>
<div><br></div><div>Every mode of IF() has its own set of variable-vs-string rules. Why does STREQUAL expect variables on both side and MATCHES doesn't? How should I remember that? Does EXISTS allow specifying a variable - or only a string will do? How should I remember that? What if I define SET(YES NO); how do I remember what IF(YES) will do?</div>
<div><br></div><div>Maybe the esteemed colleagues would suggest another good and reliable way to handle situations such as this:</div><div><br></div><div>IF (lang STREQUAL "perl") ...</div><div>ELSEIF(lang STREQUAL "python") ...</div>
<div>ELSEIF(....)</div><div>...</div><div>ENDIF ()</div><div><br></div><meta charset="utf-8"><div>without having to SET(perl perl) (and all the other cases in this switch) myself (just in case), but still being afraid that somebody, somewhere else, would SET(perl 5.10.0), and without resorting to IF (lang MATCHES "^perl$")?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">On Sat, Aug 13, 2011 at 3:39 AM, Michael Wild <<a href="mailto:themiwi@gmail.com">themiwi@gmail.com</a>> wrote:<br>
> For most users, macros should be a taboo anyways. They are much better<br></blockquote><div><br></div><div>If MACRO is taboo, deprecate it. Having an active command exhibit peculiar and hard-to-debug behaviour in conjunction with another active command is hardly a way to deter people from using it. However...</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
> served by functions, IMHO. In all of my projects I had only one case<br>
> where I actually needed a macro. That was when I wrapped a function<br>
> that set some variables in the PARENT_SCOPE and I had to propagate them<br>
> outside of the wrapping macro without knowing their name.<br></blockquote><div><br></div><div>... bingo. It is possible that we are relatively light users, but our use case involves thousands of directories, half of them libraries with complex dependency chains, 5k+ lines of specialized cmake code (not counting the per-directory CMakeLists.txt); I have tried to use functions as much as possible, and this "don't know what variables are being set and how deep my call stack is" is effectively ruling it out in most cases.</div>
<div><br></div><div>Maybe having an easier way to work with properties would help, so that they can behave like variables. Something like this, for instance:</div><div><br></div><div>${dir:var} - property for directory "dir"</div>
<div>${:var} - property for current directory</div><div>${::var} - global property</div><div><br></div><div>or</div><div><br></div><meta charset="utf-8"><meta charset="utf-8"><div>${#GLB:var}</div><div></div><div>${#DIR:dir:var}</div>
<div>${#SRC:src:var}</div><div><meta charset="utf-8"><div>${#TGT:tgt:var}</div></div><div><meta charset="utf-8"><div>${#TST:tst:var}</div></div><div><meta charset="utf-8"><div>${#CCH:entry:var}</div></div><div><br></div><div>
with all the requisite DEFINED etc. tests.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">> Perhaps it would be enough to just properly document the quirky<br>
> behaviour of macro arguments in the docs and mention that one should<br>
> normally prefer functions over macros unless there is a real reason<br>
> that requires a macro?<br></blockquote><div><br></div><div>Properly documenting everything would be nice in general. Emphasizing stumbling blocks such as these would be nice. Having a separate section on "here is what you should pay attention to" would also be nice. Documenting what happens when a command fails would be nice, too (STRING(REGEX MATCH) if no match, FILE(READ) if no file etc.) Explaining how to use STRING(FIND) with STRING(SUBSTRING), if that is even possible, and whether any sort of arithmetic is available would be good.</div>
<div><br></div><div>Maybe I missed it, but the documentation page below appeared not mention such basic stuff as how to expand a variable (the ${} syntax is kind of implied):</div><div><br></div><div><a href="http://www.cmake.org/cmake/help/cmake-2-8-docs.html">http://www.cmake.org/cmake/help/cmake-2-8-docs.html</a></div>
<div><br></div></div>