For project and target objects, save their ids in CMakeCache.txt.
Hopefully, that will be enough to allow user settings to be saved
across multiple CMake generate operations. Other object types may
also need their ids saved: if so, more code than this commit
will be necessary...
If you had a + in the name of a target with nmake, it created a variable
in the makefile that used + in its name, which is not allowed by nmake.
To make the implementation easier, + is now not allowed for any make
generators as part of a variable name.
Fix problem exposed by recent commit to FindPythonInterp.
If the find "details" has new lines in it, then replace them
with literal "\n" two character sequences so that the string
may be saved as a cache entry that can be re-read next time
CMake runs.
Using the second mode of FIND_PACKAGE_HANDLE_STANDARD_ARGS allows for
checking the version number. Now a user can require a minimum version of
the python interpreter with find_package(PythonInterp VERSION)
The old approach to determine the python executeable chooses the newest
version from _Python_VERSIONS if no additonal versions are passed.
With python it is possible to install different versions side-by-side.
Therefore a user can install e.g. python 2.5 and 2.7. Python 2.7 maybe
only installed for testing new features and 2.5 for building and running
his software. Thus the default installation for the user would be python
2.5 and then returning PYTHON_EXECUTEABLE python2.7 would be wrong. The
new approuch searches first for the the default python executable e.g.
/usr/bin/python on unix and if it can't be found _Python_VERSIONS is
used.
In --find-package mode we can't enable a language, since a lot of
stuff has not been set up, e.g. which make tool to use.
So disable enable_language() in this mode.
Alex
The test "complex" sets the variable CMAKE_BACKWARDS_COMPATIBILITY
to 1.4. When that variable is set, configure_file does not default
to IMMEDIATE mode processing. And so, the output file likely does
not exist yet by the time the next line in the CMakeLists.txt file
is processed. When that next line is "try_compile" on that file,
this is a problem.
Fix the problem by explicitly using IMMEDIATE in the configure_file
call.
This problem was quite mysterious, as it only showed up on the
"complex" test, when the previous commit introduced a CheckSymbolExists
call into the FindThreads module. Which is not even explicitly included
in the "complex" test... FindThreads gets included indirectly only
as a side effect of setting CMAKE_BACKWARDS_COMPATIBILITY to 1.4 and
even then it's included indirectly by auto-inclusion of
CMakeBackwardCompatibilityC.cmake...
Wow. Just wow.
This fixes the problem that otherwise Platforms/CYGWIN.cmake doesn't
know whether it should set WIN32 or not.
Now it uses always the current behaviour.
Alex
QNX has the phtread stuff in the standard library. The best way would
IMHO be to check if a program that uses pthread_* can be successfully
linked without specifying any linker option before trying out the
different flags.
In SystemTools::ClassInitialize, remove call to AddTranslationPath
that was originally put in place to "work around an SGI problem."
This code precluded using CMake effectively in valid directories
under "/tmp_mnt/"
To support Intel Fortran, CMake started using devenv and VCExpress
for build tools with VS2010. However, VCExpress does not always work.
This change makes CMake use MSBuild when devenv is not found. This should
be OK, since Intel Fortran can not be used with VCExpress.
David Cole
Stephen Kelly
KWSys Robot
Bill Hoffman
Björn Ricks
Alex Neundorf
Rolf Eike Beer
Johan Bjork