<div class="gmail_quote">On Fri, Mar 27, 2009 at 1:29 PM, Alexander Neundorf <span dir="ltr">&lt;<a href="mailto:a.neundorf-work@gmx.net">a.neundorf-work@gmx.net</a>&gt;</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;">
<div><div></div><div class="h5">On Friday 27 March 2009, Philip Lowman wrote:<br>
&gt; On Thu, Mar 26, 2009 at 10:23 PM, Robert Dailey &lt;<a href="mailto:rcdailey@gmail.com">rcdailey@gmail.com</a>&gt; wrote:<br>
&gt; &gt; I&#39;m assuming that the macro in question will automatically mark all cache<br>
&gt; &gt; variables as advanced. Is this the case?<br>
&gt; &gt;<br>
&gt; &gt; @Mike Jackson<br>
&gt; &gt; Thank you for this info. I forgot about that function.<br>
&gt; &gt;<br>
&gt; &gt; There seems to be an inconsistency in naming convention. For example, the<br>
&gt; &gt; set() function uses the term INTERNAL to represent a &quot;hidden&quot; cache<br>
&gt; &gt; variable. However, the function mark_as_advanced() is using the term<br>
&gt; &gt; &quot;advanced&quot;. What I would like to see is one of the following pairs:<br>
&gt; &gt;<br>
&gt; &gt; set( CACHE ADVANCED )<br>
&gt; &gt; mark_as_advanced()<br>
&gt; &gt;<br>
&gt; &gt;  - OR -<br>
&gt; &gt;<br>
&gt; &gt; set( CACHE INTERNAL )<br>
&gt; &gt; mark_as_internal()<br>
&gt; &gt;<br>
&gt; &gt; Does this make sense, or am I misunderstanding the difference between the<br>
&gt; &gt; two?<br>
&gt;<br>
&gt; You can consider INTERNAL &quot;super advanced&quot;.  It won&#39;t get shown in the<br>
&gt; cache editor at all.  I think if you want an internal cache variable it<br>
&gt; probably should be created as an INTERNAL.  In general you probably want to<br>
&gt; avoid using INTERNAL unless you really need it.  Think of INTERNAL as a<br>
&gt; friendlier way to use set(...FORCE CACHE).  Basically you&#39;re setting a<br>
&gt; cache variable you want to be persistent, but you don&#39;t want to confuse the<br>
&gt; user into thinking they have a choice in changing it.<br>
&gt;<br>
&gt; Marking a variable as advanced is more of a discretionary thing.  Generally<br>
&gt; when writing a find module a good rule of thumb is do not<br>
&gt; mark_as_advanced() by default.  Generally, leave the user calling<br>
&gt; find_package() to do this and assume they care about the location of the<br>
&gt; library.<br>
<br>
</div></div>I think I have to object here.<br>
AFAIK the CMake devs prefer to basically use mark_as_advanced() by default for<br>
all results from find_library/program/path/file() in find-modules, and only<br>
keep those entries visible in the simple view which should be<br>
user-adjustable.<br>
E.g. for FindQt4.cmake I think the only non-advanced variable is<br>
QT_QMAKE_EXECUTABLE, since this is the one which basically decides about all<br>
other variables.<br>
Or options which adjust how the project will be built should be non-advanced.<br>
</blockquote><div><br>I stand corrected.  Far more find modules than I expected use mark_as_advanced() to at least some extent.<br> <br>$ grep -i mark_as_advanced Find* | cut -f1 -d : |sort |uniq |wc<br>     71      71    1219<br>
$ ls -1 Find* |wc<br>    120     120    2114<br></div></div><br>-- <br>Philip Lowman<br>