[CMake] cmake-gui leaves CMAKE_<language>_COMPILER_WORKS undefined for simple test case and CMake-2.6.4

[David Cole]

On Thu, Jul 16, 2009 at 4:23 PM, Alan W. Irwin <irwin at beluga.phys.uvic.ca>wrote:

> On 2009-07-16 13:51-0400 Bill Hoffman wrote:
>
>  I am not really sure what this issue is...
>>
>>
>> This is certainly not an expected use case:
>>
>> include(CMakeDetermine<language>Compiler)
>> before
>> enable_language(<language> OPTIONAL)
>>
>> If you look in cmGlobalGenerator.cxx there is a big comment about how all
>>
> the$
>
>> files work together to enable a language.  I am not surprised that
>> including
>> this stuff out of order is causing trouble.  I am also not sure why the
>> gui's
>> would be different...
>>
>> The right thing would be to implement the OPTIONAL part.  I don't know if
>> I
>> will have time for this before 2.8 (patches are welcome...).
>>
>
> With regard to the differences between the good cmake results on the one
> hand and the bad ccmake and cmake-gui results on on the other hand for my
> simple but nonstandard example, I agree that CMake language support is sort
> of a "magical" area of CMake so it is perhaps not too surprising that using
> it in this unanticipated way exposes differences between the various cmake
> applications. So given your time constraints you may want to just cross
> your
> fingers and let this exposed issue slide.
>
> However, that exposed issue was discovered because I needed a workaround
> for
> bug 9220 so I agree the fundamental thing to do would be to deal with bug
> 9220.
>
>
> On 2009-07-16 14:12-0400 Bill Hoffman wrote:
>
>  David Cole wrote:
>>
>>> 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'd have to use your own variables to
>>> track with this technique and not rely on the built-in ones.
>>>
>>>
>> That is a good idea, and it would work with any version of cmake.
>>
>
> Hi David:
>
> I think you inadvertently posted your comment off list so I hope you don't
> mind if I quote you (and also Bill's response to your idea) on list.
>
> Thanks for that good idea for a temporary workaround to bug 9220. Your idea
> even takes care of the broken compiler case.  (My attempted workaround only
> took care of the missing compiler case.) I will implement that workaround
> for now for the PLplot build system, but that's a little complicated for
> most projects that want to implement a soft landing when compilers are
> missing/broken.  So fixing bug 9220 is obviously the best long-term
> solution.
>
>
I agree. Fixing bug 9220 is the best solution.

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.

At any rate, I do not consider anything I say through email to be "private"
in any sense, so I do not mind you quoting me. :-)

Hope it works as a work-around for now.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090716/634357e0/attachment.htm>