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
