<div class="gmail_quote">On Thu, Jul 16, 2009 at 4:23 PM, Alan W. Irwin <span dir="ltr">&lt;<a href="mailto:irwin@beluga.phys.uvic.ca">irwin@beluga.phys.uvic.ca</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 2009-07-16 13:51-0400 Bill Hoffman wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am not really sure what this issue is...<br>
<br>
<br>
This is certainly not an expected use case:<br>
<br>
include(CMakeDetermine&lt;language&gt;Compiler)<br>
before<br>
enable_language(&lt;language&gt; OPTIONAL)<br>
<br>
If you look in cmGlobalGenerator.cxx there is a big comment about how all<br>
</blockquote>
the$<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
files work together to enable a language.  I am not surprised that including<br>
this stuff out of order is causing trouble.  I am also not sure why the gui&#39;s<br>
would be different...<br>
<br>
The right thing would be to implement the OPTIONAL part.  I don&#39;t know if I<br>
will have time for this before 2.8 (patches are welcome...).<br>
</blockquote>
<br></div>
With regard to the differences between the good cmake results on the one<br>
hand and the bad ccmake and cmake-gui results on on the other hand for my<br>
simple but nonstandard example, I agree that CMake language support is sort<br>
of a &quot;magical&quot; area of CMake so it is perhaps not too surprising that using<br>
it in this unanticipated way exposes differences between the various cmake<br>
applications. So given your time constraints you may want to just cross your<br>
fingers and let this exposed issue slide.<br>
<br>
However, that exposed issue was discovered because I needed a workaround for<br>
bug 9220 so I agree the fundamental thing to do would be to deal with bug<br>
9220.<div><div></div><div class="h5"><br>
<br>
On 2009-07-16 14:12-0400 Bill Hoffman wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
David Cole wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another work around might be doing an execute_process with another CMake that processes a one-line file with an enable_language call in it... If it fails to configure, the caller of execute_process could fail gracefully rather than with the hard error that an enable_language call currently gives. And if it succeeds, then presumably it would be safe to call enable_language for that language... You&#39;d have to use your own variables to track with this technique and not rely on the built-in ones.<br>

<br>
</blockquote>
<br>
That is a good idea, and it would work with any version of cmake.<br>
</blockquote>
<br></div></div>
Hi David:<br>
<br>
I think you inadvertently posted your comment off list so I hope you don&#39;t<br>
mind if I quote you (and also Bill&#39;s response to your idea) on list.<br>
<br>
Thanks for that good idea for a temporary workaround to bug 9220. Your idea<br>
even takes care of the broken compiler case.  (My attempted workaround only<br>
took care of the missing compiler case.) I will implement that workaround<br>
for now for the PLplot build system, but that&#39;s a little complicated for<br>
most projects that want to implement a soft landing when compilers are<br>
missing/broken.  So fixing bug 9220 is obviously the best long-term<br>
solution.<div><div></div><div class="h5"><br></div></div></blockquote></div><div><br></div><div>I agree. Fixing bug 9220 is the best solution.</div><div><br></div><div>I replied directly to you and Bill because I thought it would be a good idea to try it out first before posting to the list... and I did not have time to try it, but I thought maybe you would.</div>
<div><br></div><div>At any rate, I do not consider anything I say through email to be &quot;private&quot; in any sense, so I do not mind you quoting me. :-)</div><div><br></div><div>Hope it works as a work-around for now.</div>
<div><br></div><div>David</div><div><br></div>