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

David Cole david.cole at kitware.com
Mon Oct 29 13:16:17 EDT 2012


On Sat, Oct 27, 2012 at 4:25 AM, Alan W. Irwin
<irwin at 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 you've found
with respect to additional language support files, but please let me
know if you disagree with that opinion after you've read this email.

The issue you've reported was introduced by this commit:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7195aca54f40778f41894c9e62649afe09e71d6c

As you can see from the commit itself, all of the built-in language
support files changed something like this:

  -  ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeASM...
  +  ${CMAKE_PLATFORM_INFO_DIR}/CMakeASM...

CMake now configures/writes the files resulting from an
enable_language call into a directory named by a new variable:
CMAKE_PLATFORM_INFO_DIR. That variable's contents has a subdirectory
at the end of it that is specific to the actual version of CMake.

It's ironic that this commit caused a problem for you, since the
stated intent of the commit (read the commit message, it's quite
informative) is to make it more reliable to build an existing build
tree after upgrading to a new version of CMake.

I think the best path forward is to change your language support files
with a change similar to the changes that were made to the built-in
files. You could even use the following chunk at the top of your
language support files so that they can be used with 2.8.10 *and* also
with earlier builds of CMake:

  if(NOT CMAKE_PLATFORM_INFO_DIR)
    set(CMAKE_PLATFORM_INFO_DIR
      ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY})
  endif()

and then reference ${CMAKE_PLATFORM_INFO_DIR} wherever necessary.

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.

We are hoping to make the 2.8.10 release final this week, and have an
official release of CMake that supports the latest Visual Studio and
Xcode versions.


Thanks,
David



More information about the cmake-developers mailing list