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.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
