On Thu, Jul 16, 2009 at 4:23 PM, Alan W. Irwin <[email protected]>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
_______________________________________________ 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
