Re: [cmake-developers] Fortran detection, issue 9220
Here is one more extremely simple idea for solving this bug. Assuming all of CMake always errors out using the same piece of error-processing code, couldn't enable_language(OPTIONAL) immediately set an internal variable which is honored by that error-processing code to turn all further errors into warnings? Then the last thing enable_language(OPTIONAL) should do is unset that variable (so all further errors are treated as errors) before returning control to the logic that called enable_language(OPTIONAL). Of course, this idea depends on the assumption that all CMake errors are handled by the same piece of error-processing code, but if that is true this fix should be extremely easy to implement. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Fortran detection, issue 9220
On Wed, Feb 11, 2015 at 09:44:26 -0500, Brad King wrote: We already guarantee that CMAKE_LANG_COMPILER is set, so we could indicate failure simply by having it not set. Well, the problem is that that is valid in Ninja. It might be available, but it isn't going to be useful. Also one would need to decide what determines whether an optional language is not available. If a compiler is available but cannot compile binaries, should that be an error or tolerated as not available? As a user I would expect setting FC=/path/to/gfortran in my environment before calling CMake to cause Fortran to be enabled if the project wants it or else an error. I guess there are two different issues here. Some projects want Fortran if available (or even to just see whether it is available) while Ninja needs to error out on Fortran because it just can't get the build correct. So, IMO, my patch should be completely orthogonal to the OPTIONAL keyword logic; Ninja doesn't care whether you have Fortran or not, it just can't build it for you. We already treat unknown extensions like .txt files in most cases, so this would have to be specific to languages that were OPTIONAL and failed to be enabled. Hrm. Yeah, that could be tricky. --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Fortran detection, issue 9220
On Tue, Feb 10, 2015 at 21:48:39 -0800, Alan W. Irwin wrote: Sorry, but I still think the general Ninja problems with Fortran are orthogonal to this general language support issue. Or are you implying that enable_language(OPTIONAL) works for Ninja now for all languages other than Fortran? No, I didn't have OPTIONAL at all. All the branch does is move the error case from I need/want Fortran to I'm building this Fortran source file. I frankly don't understand this comment at all. I am sure you would agree with me that CMake has complete knowledge of how to build applications and libraries with a wide variety of compilers. So I probably just completely missed your point. CMake doesn't have any support for getting proper dependencies from Ada for example. So while you could use add_custom_command to *build* Ada files, build-time dependency scanning for things like #include or import without a reconfigure aren't supported. Supporting a language is more than just providing rules to build files of that type. Agreed. It's probably an extremely tedious task to go through all the code paths (including all generators and all compiled languages) for modern CMake language support that are executed by the enable_language(... OPTIONAL) command, and change all potential CMake error exits to warnings for that case. And I don't have the C++ skill or knowledge of CMake internals to help out with this tedious task myself. So I completely understand why a fix for bug 9220 has still not been accomplished after all these years. But it sure is a would be nice. A sketch for anyone interested (probably still not complete, but it's things to look for): - change cmGlobalGenerator::EnableLanguage to return a bool; - add CMAKE_LANG_FOUND variables to indicate support for a language is available; - trigger an error when build rules for an unsupported language are encountered. The patch I referenced basically does the last bit for Ninja+Fortran. --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Fortran detection, issue 9220
On 02/11/2015 09:26 AM, Ben Boeckel wrote: A sketch for anyone interested (probably still not complete, but it's things to look for): - change cmGlobalGenerator::EnableLanguage to return a bool; - add CMAKE_LANG_FOUND variables to indicate support for a language is available; We already guarantee that CMAKE_LANG_COMPILER is set, so we could indicate failure simply by having it not set. Also one would need to decide what determines whether an optional language is not available. If a compiler is available but cannot compile binaries, should that be an error or tolerated as not available? As a user I would expect setting FC=/path/to/gfortran in my environment before calling CMake to cause Fortran to be enabled if the project wants it or else an error. - trigger an error when build rules for an unsupported language are encountered. We already treat unknown extensions like .txt files in most cases, so this would have to be specific to languages that were OPTIONAL and failed to be enabled. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Fortran detection, issue 9220
On 2015-02-11 09:44-0500 Brad King wrote: Also one would need to decide what determines whether an optional language is not available. If a compiler is available but cannot compile binaries, should that be an error or tolerated as not available? As a user I would expect setting FC=/path/to/gfortran in my environment before calling CMake to cause Fortran to be enabled if the project wants it or else an error. Tolerated with a warning please. Unsophisticated users could have environment variables set that they are completely unaware of. And I have run across scientific users of Fortran who assumed that Fortran compiler options (which can be set either with the FC variable or FFLAGS) were universal regardless of compiler (so they were inadvertently attempting to use some exotic solaris fortran compiler options for gfortran). From these experiences with unsophisticated compiler users, my own feeling is OPTIONAL should mean just that, i.e., warn instead of error out for all cases. That's how we currently deploy the workaround for PLplot, and I have never had a user complaint about getting those soft landings when a compiler didn't work properly. (Maybe because our warning messages are really obvious when a compiler does not work.) 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Fortran detection, issue 9220
Hi! I second Alan's view. The test should warn when it fails but still keep running. This includes Ninja, which would warn but still run through. I would like to get a variable language_WORKS for every enable_language(language OPTIONAL). Then I could disable features that depends on that specific language. Should I open a new bug or summarize our discussion in issue #9220? Best, Christoph -- When you die, that does not mean that you lose to cancer, you beat cancer by how you live, why you live, and in the manner in which you live. -- Stuart Scott, 1965-2015 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Fortran detection, issue 9220
On Tue, Feb 10, 2015 at 17:15:33 -0800, Alan W. Irwin wrote: As the originator (almost 6 years ago) of this bug report I am still very much interested in a fundamental solution to give a WARNING message rather than an error if there is any issue with a compiler. This patch makes it only an error when Ninja detects a Fortran compiler rule being written (which is where the actual incompatibility lies). Other languages error out because CMake doesn't have *any* knowledge of how to build them. Java is kinda-sorta there IIRC. I haven't used it much, but I don't remember it feeling first-class. That capability is fundamentally important for projects like PLplot that support more than one different compiled computer language (PLplot supports the compiled languages Ada, C, C++, Fortran, D, and Java) You might be interested in the first-class D support here where I've been dabbling in some personal projects: https://github.com/trentforkert/cmake Other languages would need similar efforts to be fully supported. That said, putting logic behind enable_language(OPTIONAL) would be nice. --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Fortran detection, issue 9220
On 2015-02-06 10:21-0500 Ben Boeckel wrote: On Fri, Feb 06, 2015 at 07:01:55 +0100, Christoph Grüninger wrote: would you mind to tackle issue 9220 enable_language( OPTIONAL) signature does not work correctly? It's a shame that CMake cannot properly detect optional Fortran for more than 5 years! The workaround from Eigen works fine for me, but it's still embarrassing. BTW, is there a way to disable the optional Fortran by a flag to CMake? I couldn't find any... Here is a commit which I haven't worked on for a while which delays the error until you request an actual build of a Fortran object: https://github.com/mathstuf/CMake/commit/880d783bf7fbd986b8a50a712e69ff40abbcfa07 While not the OPTIONAL signature, it is more accurate. Let me know how it works for you. Some additional comments for both Christoph and Ben: This issue is for all language compilers, not just Fortran, and this issue is orthogonal to the well-known lack of support for Fortran in ninja. As the originator (almost 6 years ago) of this bug report I am still very much interested in a fundamental solution to give a WARNING message rather than an error if there is any issue with a compiler. That capability is fundamentally important for projects like PLplot that support more than one different compiled computer language (PLplot supports the compiled languages Ada, C, C++, Fortran, D, and Java) where the project developer's want users to at least have partial functionality if say the Ada compiler does not work. We do have a workaround (see early comments in http://public.kitware.com/Bug/view.php?id=9220 for details), but that approach is inefficient (you have to check compilers twice), and doesn't correctly propagate all the many different ways (e.g., environment variables, CMake cache variables) you can specify compilers and compiler flags to the special small CMake test build system used to check the compiler for each required compiled language. The most recent comment (by Brad King) at http://public.kitware.com/Bug/view.php?id=9220 states the documentation has now been changed to state that OPTIONAL is a placeholder (in enable_language) that does not work. So at least OPTIONAL has now been clearly marked as defunct. Brad also recommends an alternative approach to using OPTIONAL in enable_language. I haven't had a chance to look into that possibility yet, but I will do so because an efficient and clean solution for providing a soft landing when a compiler test fails is important for the PLplot project. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Fortran detection, issue 9220
On Fri, Feb 06, 2015 at 07:01:55 +0100, Christoph Grüninger wrote: would you mind to tackle issue 9220 enable_language( OPTIONAL) signature does not work correctly? It's a shame that CMake cannot properly detect optional Fortran for more than 5 years! The workaround from Eigen works fine for me, but it's still embarrassing. BTW, is there a way to disable the optional Fortran by a flag to CMake? I couldn't find any... Here is a commit which I haven't worked on for a while which delays the error until you request an actual build of a Fortran object: https://github.com/mathstuf/CMake/commit/880d783bf7fbd986b8a50a712e69ff40abbcfa07 While not the OPTIONAL signature, it is more accurate. Let me know how it works for you. --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Fortran detection, issue 9220
Hi CMake developers, would you mind to tackle issue 9220 enable_language( OPTIONAL) signature does not work correctly? It's a shame that CMake cannot properly detect optional Fortran for more than 5 years! The workaround from Eigen works fine for me, but it's still embarrassing. BTW, is there a way to disable the optional Fortran by a flag to CMake? I couldn't find any... Bye Christoph -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
