Re: [cmake-developers] Regression in language support infrastructure for CMake 2.8.10-rc3
On 10/29/2012 10:17 PM, Alan W. Irwin wrote:
if(NOT CMAKE_PLATFORM_INFO_DIR)
set(CMAKE_PLATFORM_INFO_DIR
${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY})
endif()
to handle the case of versions of CMake prior to 2.8.10.
(You covered this OK, but I believe you should also be more specific
about the location where the above instructions are placed. I assume
the above CMake logic fragment should be inserted just before the
project command if the specified language is mentioned in that project
command, and before the enable_language command for that specified
language otherwise. However, the advice on location should be stated.)
It should be at the top of CMake${lang}Information.cmake and of
the configured CMake${lang}Compiler.cmake. The former is the first
file to be loaded for a language the first time it is enabled in a
new build tree. The latter is the first file loaded for a language
in an existing build tree.
In sum, I was completely surprised by this backwards-incompatible
change for CMake-2.8.10, but if you follow my suggestions about
announcing the change and documenting what has to be done to keep
external language support working, that element of surprise should be
greatly reduced for other external project developers who are
supporting various languages.
The implementation behind the scenes of project/enable_language,
including the compiler/platform modules, is an *internal* API that
does not make any compatibility guarantees. It is not covered in the
official reference documentation that is versioned with the source code.
Maintainers of external language support are responsible for porting
it to each version of CMake as upstream changes are made.
We do provide nightly tarballs of the 'next' branch. If you test with
that you will catch these changes as soon as they are made which would
give everyone much more time to deal with them than waiting until rc3.
-Brad
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Regression in language support infrastructure for CMake 2.8.10-rc3
On 2012-10-30 08:30-0400 Brad King wrote: In sum, I was completely surprised by this backwards-incompatible change for CMake-2.8.10, but if you follow my suggestions about announcing the change and documenting what has to be done to keep external language support working, that element of surprise should be greatly reduced for other external project developers who are supporting various languages. The implementation behind the scenes of project/enable_language, including the compiler/platform modules, is an *internal* API that does not make any compatibility guarantees. It is not covered in the official reference documentation that is versioned with the source code. Maintainers of external language support are responsible for porting it to each version of CMake as upstream changes are made. Umm, it's not completely internal. Modules/CMakeAddNewLanguage.txt does document in a very terse way what has to be done to add a new language externally. Basically what you are saying is it's our current policy, and it sounds like your group has made the decision about what that current policy is going to be. Nevertheless, I still think you should advertise this limitation on your backwards compatibility further. It's not covered is not enough. You should also have a big fat warning in Modules/CMakeAddNewLanguage.txt about this current policy. In sum, if you agree that implementation of additional computer language support is ultimately going to be a tremendous benefit to CMake, then you should be encouraging such efforts rather than discouraging them. As I have said before, that doesn't necessarily mean the extreme measure of no backwards incompatible changes allowed in language support. However, any easy steps you could do (such as mentioning backwards-incompatible breakage for language support in release announcements) would be an obvious help. Also, I will take your suggestion to heart to test forthcoming CMake releases more thoroughly. I don't have the time to do that manually, but I am aware there is a way (once I can find the time to implement it) to automate such tests with the ctest and dashboard capability associated with CMake. That's been on my ToDo list for a long time, but this incident will substantially bump the priority of this. 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 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Regression in language support infrastructure for CMake 2.8.10-rc3
On 10/30/2012 01:43 PM, Alan W. Irwin wrote: Umm, it's not completely internal. Modules/CMakeAddNewLanguage.txt does document in a very terse way what has to be done to add a new language externally. Basically what you are saying is it's our current policy, and it sounds like your group has made the decision about what that current policy is going to be. Nevertheless, I still think you should advertise this limitation on your backwards compatibility further. It's not covered is not enough. You should also have a big fat warning in Modules/CMakeAddNewLanguage.txt about this current policy. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=854369fd -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Regression in language support infrastructure for CMake 2.8.10-rc3
On 10/30/2012 2:06 PM, Brad King wrote: Basically what you are saying is it's our current policy, and it sounds like your group has made the decision about what that current policy is going to be. Nevertheless, I still think you should advertise this limitation on your backwards compatibility further. It's not covered is not enough. You should also have a big fat warning in Modules/CMakeAddNewLanguage.txt about this current policy. The intention always was that new language support would be donated upstream and become part of CMake. This would of course require testing and cross platform support for the language. However, that was always the expectation. -Bill -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Regression in language support infrastructure for CMake 2.8.10-rc3
On Sat, Oct 27, 2012 at 4:25 AM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: On 2012-10-24 16:39-0400 David Cole wrote: The CMake 2.8.10 release candidate stream continues! This is the last RC unless somebody finds a critical, must-fix issue with it. As you know I have been distracted by CMake on Wine issues for some time, and that is probably going to continue for a while, but just to do my duty I just now tried a standard PLplot build on Linux with rc3, and I am sorry to say there is a serious regression in the language support infrastructure relative to 2.8.9. Our Ada and D language support are both fine with 2.8.9, but both crap out with rc3. You may recall that our language support uses a workaround for bug 9220 (which is _still_ my top-priority bug for each release since that workaround is far from perfect and doubles enabling time for each language). The workaround (suggested by you years ago) uses a temporary workaround project in language_tests/Language to check whether language support works for a particular language. If that workaround project succeeds (with all build files stored in language_tests/Language, PLplot goes ahead and enables that language for real, but if not, it warns the user of the language issue and what will be removed from PLplot as a result, and moves on rather than erroring out. That workaround is working for all languages other than Ada and D as well as it ever did, but I brought it up because you will see the ERROR messages in the attached file of the 2.8.10-rc3 cmake output (and similarly for 2.8.9 cmake output for comparison) from the workaround project and would otherwise be surprised that our build system survives those errors when they occur. Now on to the rc3 errors: The error messages for the simple workaround project to check Ada start with CMake Error: Could not find cmake module file:/home/software/plplot_svn/HEAD/build_dir/language_tests/Ada/CMakeFiles/2.8.10-rc3/CMakeAdaCompiler.cmake And the rc3 error messages for the simple workaround project to check D start with CMake Error: Could not open file for write in copy operation /CMakeDCompiler.cmake.tmp So it appears to me that locations have been changed for 2.8.10 where CMake language support expects configured and other files to be. I haven't really been following 2.8.10 development that closely, but has there been such an obviously backwards-incompatible change in how language support works? Of course, this is probably the most non-ideal moment to discover something like this for me because I am still in the middle of the CMake-Wine tests, and I am sure it is a non-ideal moment for you as well. But I really do think the 2.8.10 release should be delayed until this issue is sorted out. I am certainly willing to cooperate on this end in as timely a manner as possible with any tests/simple projects that help to figure this out. Of course, I am also willing to make any change the CMake developers feel is necessary (so long as it doesn't break Ada and D language support for older versions of CMake) in our Ada and D language support, but I think that is a last resort. After all, we have only made minor modifications to the D language Cmake approach given at http://www.dsource.org/projects/cmaked so, for example, a change to just our D language support is going to leave others out in the cold. For the Ada case, I am aware of at least one other major project that depends on Ada language support. (To help identify this project, there was a long discussion with Bill recently from this guy implementing the project, but I am too tired to look him up any better than that.) I don't know for sure that that project will be affected by this CMake-2.8.10 regression in language support, but it is likely. Finally we already have a simple but self-contained Ada test project which can be obtained by svn checkout \ https://plplot.svn.sourceforge.net/svnroot/plplot/branches/test_cmake/test_ada I have just confirmed that simple project works fine with 2.8.9 and does not work with 2.8.10-rc3 so perhaps the CMake developers should start with a checkout of that simple project to help figure out what has gone wrong. 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 __ Alan, Thanks for trying the CMake release candidates. I don't think we should delay the release for this issue
Re: [cmake-developers] Regression in language support infrastructure for CMake 2.8.10-rc3
On 2012-10-29 13:16-0400 David Cole wrote: The bottom line is: we changed where the output files of an enable_language call go to make them exact-version-of-CMake-specific. Anybody who was depending on the location of those files needs to update their own code accordingly. I think the number of people/projects affected by this should be quite small... Admittedly: for those that are affected (you, sorry), it's annoying, but it should be easy to apply the above type changes and have your custom language support files work for older and newer versions of CMake. Please let me know if this seems reasonable to you. Hi Dave: You guys have a very good track record for keeping backwards compatibility, but language support is a really special area with relatively few groups adding language support externally (although it is clear more groups than the PLplot group do this). Therefore, I completely understand why you guys are tempted to go against your track record and simply make this backwards incompatible change without adding any complications to keep backwards compatibility. Also, from what you have said it does seem straightforward (although I haven't tried it yet) to modify a particular language's support so it works with the new language support infrastructure as well as the old. How about this for a compromise? Add a note to your release notes that announces this backwards incompatibility introduced into the language support infrastructure for 2.8.10. That note should include most of the contents of your e-mail to me about the practical steps required for external project's language support to work both with old and new language support infrastructure. Or, better yet, point to a text file that is part of the 2.8.10 and future releases that contains this essential information. Also _ideally_ you should check that those update instructions actually work for the simple Ada project that you can easily obtain with svn checkout \ https://plplot.svn.sourceforge.net/svnroot/plplot/branches/test_cmake/test_ada I will be applying your instructions to update our D language support after lunch. If those work, I will follow up by doing the same thing for Ada (if you don't beat me to it with a patch for how the simple Ada project can be updated). Presumably I will be able to give you feedback on your instructions by late this afternoon (evening your time). At this point I am not actually completely convinced your instructions will work since both D and Ada language support have been around a long time and are not nearly as modernized as the core language support that appears in CMake-2.8.9. With luck, that will not be an issue for either D or Ada, but we will see. You might want to consider delaying your release until you get feedback from me on your instructions, but that decision is up to you. 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 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Regression in language support infrastructure for CMake 2.8.10-rc3
On Mon, Oct 29, 2012 at 4:36 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: On 2012-10-29 13:16-0400 David Cole wrote: The bottom line is: we changed where the output files of an enable_language call go to make them exact-version-of-CMake-specific. Anybody who was depending on the location of those files needs to update their own code accordingly. I think the number of people/projects affected by this should be quite small... Admittedly: for those that are affected (you, sorry), it's annoying, but it should be easy to apply the above type changes and have your custom language support files work for older and newer versions of CMake. Please let me know if this seems reasonable to you. Hi Dave: You guys have a very good track record for keeping backwards compatibility, but language support is a really special area with relatively few groups adding language support externally (although it is clear more groups than the PLplot group do this). Therefore, I completely understand why you guys are tempted to go against your track record and simply make this backwards incompatible change without adding any complications to keep backwards compatibility. Also, from what you have said it does seem straightforward (although I haven't tried it yet) to modify a particular language's support so it works with the new language support infrastructure as well as the old. How about this for a compromise? Add a note to your release notes that announces this backwards incompatibility introduced into the language support infrastructure for 2.8.10. That note should include most of the contents of your e-mail to me about the practical steps required for external project's language support to work both with old and new language support infrastructure. Or, better yet, point to a text file that is part of the 2.8.10 and future releases that contains this essential information. Also _ideally_ you should check that those update instructions actually work for the simple Ada project that you can easily obtain with svn checkout \ https://plplot.svn.sourceforge.net/svnroot/plplot/branches/test_cmake/test_ada I will be applying your instructions to update our D language support after lunch. If those work, I will follow up by doing the same thing for Ada (if you don't beat me to it with a patch for how the simple Ada project can be updated). Presumably I will be able to give you feedback on your instructions by late this afternoon (evening your time). At this point I am not actually completely convinced your instructions will work since both D and Ada language support have been around a long time and are not nearly as modernized as the core language support that appears in CMake-2.8.9. With luck, that will not be an issue for either D or Ada, but we will see. You might want to consider delaying your release until you get feedback from me on your instructions, but that decision is up to you. 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 __ The release is delayed already... I'm not going to start building the final release until after I hear back from you. There are still several discussions going on around this issue. So do let me know your results. Thanks, 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Regression in language support infrastructure for CMake 2.8.10-rc3
On 2012-10-29 17:36-0400 David Cole wrote:
The release is delayed already... I'm not going to start building the
final release until after I hear back from you. There are still
several discussions going on around this issue. So do let me know
your results.
OK. I have tested results for both 2.8.9 and 2.8.10-rc3, and all is
well now with the updated PLplot Ada and D language support (and also
the updated mini-project's Ada language support). Thanks very much
for your instructions and in particular the link to Brad's commit
message which clarified most issues.
However, it took much longer than it should have because I had some trouble
following your instructions. So assuming you do create documentation
of the changes that must be made to deal with these
backwards-incompatible changes, I suggest that documentation start
(and maybe even end depending on what Brad King says) with these three
key points.
* Replace CMAKE_PLATFORM_ROOT_BIN by CMAKE_PLATFORM_INFO_DIR everywhere.
(Your previous instructions only referred to this indirectly via
Brad's commit message.)
* Replace ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY} by
${CMAKE_PLATFORM_INFO_DIR} in just the few places which
involve a *.cmake file.
(I am not sure it is limited quite that rigorously in general, but
that limit worked for me. The essential point is the combination
${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY} appears throughout
language support files, and virtually in all cases should be left
alone with just a few exceptions. Thus, some way to specify
_which_ of these instances need to be changed should be
mentioned in the documentation.)
* Specify
if(NOT CMAKE_PLATFORM_INFO_DIR)
set(CMAKE_PLATFORM_INFO_DIR
${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY})
endif()
to handle the case of versions of CMake prior to 2.8.10.
(You covered this OK, but I believe you should also be more specific
about the location where the above instructions are placed. I assume
the above CMake logic fragment should be inserted just before the
project command if the specified language is mentioned in that project
command, and before the enable_language command for that specified
language otherwise. However, the advice on location should be stated.)
So PLplot (and the mini-project for Ada) are fine now. However, I
think a specific announcment of this backwards-incompatible change
should be in the 2.8.10 release announcement with a pointer to a file
containing documentation about what has to be done (as above) to
adjust to this change in language support infrastructure.
In sum, I was completely surprised by this backwards-incompatible
change for CMake-2.8.10, but if you follow my suggestions about
announcing the change and documenting what has to be done to keep
external language support working, that element of surprise should be
greatly reduced for other external project developers who are
supporting various languages.
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
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Regression in language support infrastructure for CMake 2.8.10-rc3
On 2012-10-24 16:39-0400 David Cole wrote: The CMake 2.8.10 release candidate stream continues! This is the last RC unless somebody finds a critical, must-fix issue with it. As you know I have been distracted by CMake on Wine issues for some time, and that is probably going to continue for a while, but just to do my duty I just now tried a standard PLplot build on Linux with rc3, and I am sorry to say there is a serious regression in the language support infrastructure relative to 2.8.9. Our Ada and D language support are both fine with 2.8.9, but both crap out with rc3. You may recall that our language support uses a workaround for bug 9220 (which is _still_ my top-priority bug for each release since that workaround is far from perfect and doubles enabling time for each language). The workaround (suggested by you years ago) uses a temporary workaround project in language_tests/Language to check whether language support works for a particular language. If that workaround project succeeds (with all build files stored in language_tests/Language, PLplot goes ahead and enables that language for real, but if not, it warns the user of the language issue and what will be removed from PLplot as a result, and moves on rather than erroring out. That workaround is working for all languages other than Ada and D as well as it ever did, but I brought it up because you will see the ERROR messages in the attached file of the 2.8.10-rc3 cmake output (and similarly for 2.8.9 cmake output for comparison) from the workaround project and would otherwise be surprised that our build system survives those errors when they occur. Now on to the rc3 errors: The error messages for the simple workaround project to check Ada start with CMake Error: Could not find cmake module file:/home/software/plplot_svn/HEAD/build_dir/language_tests/Ada/CMakeFiles/2.8.10-rc3/CMakeAdaCompiler.cmake And the rc3 error messages for the simple workaround project to check D start with CMake Error: Could not open file for write in copy operation /CMakeDCompiler.cmake.tmp So it appears to me that locations have been changed for 2.8.10 where CMake language support expects configured and other files to be. I haven't really been following 2.8.10 development that closely, but has there been such an obviously backwards-incompatible change in how language support works? Of course, this is probably the most non-ideal moment to discover something like this for me because I am still in the middle of the CMake-Wine tests, and I am sure it is a non-ideal moment for you as well. But I really do think the 2.8.10 release should be delayed until this issue is sorted out. I am certainly willing to cooperate on this end in as timely a manner as possible with any tests/simple projects that help to figure this out. Of course, I am also willing to make any change the CMake developers feel is necessary (so long as it doesn't break Ada and D language support for older versions of CMake) in our Ada and D language support, but I think that is a last resort. After all, we have only made minor modifications to the D language Cmake approach given at http://www.dsource.org/projects/cmaked so, for example, a change to just our D language support is going to leave others out in the cold. For the Ada case, I am aware of at least one other major project that depends on Ada language support. (To help identify this project, there was a long discussion with Bill recently from this guy implementing the project, but I am too tired to look him up any better than that.) I don't know for sure that that project will be affected by this CMake-2.8.10 regression in language support, but it is likely. Finally we already have a simple but self-contained Ada test project which can be obtained by svn checkout \ https://plplot.svn.sourceforge.net/svnroot/plplot/branches/test_cmake/test_ada I have just confirmed that simple project works fine with 2.8.9 and does not work with 2.8.10-rc3 so perhaps the CMake developers should start with a checkout of that simple project to help figure out what has gone wrong. 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 __ 2.8.10-rc3_cmake.out.gz Description: Binary data 2.8.9_cmake.out.gz Description: Binary data -- 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
