[cmake-developers] Regression in language support infrastructure for CMake 2.8.10-rc3

Alan W. Irwin irwin at beluga.phys.uvic.ca
Tue Oct 30 13:43:06 EDT 2012


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
__________________________



More information about the cmake-developers mailing list