CMakeSystemSpecificInformation.cmake into a separate file,
CMakeEclipseCDT4.cmake
-if CMAKE_EXTRA_GENERATOR is set, i.e. either CodeBlocks or KDevelop3 or
EclipseCDT4, load a matching cmake script file, which can do things specific
for this generator
- added such files for Eclipse, KDevelop and CodeBlocks, one thing they all
do is they try to find the respective IDE and store it in the
CMAKE_(KDEVELOP3|CODEBLOCKS|ECLIPSE)_EXECUTABLE variable.
This could be used by cmake-gui to open the project it just generated with
the gui (not sure this is possible with eclipse).
Alex
its system include directories. These are catched in CMakeSystemSpecificInformation.cmake
(only with the Eclipse generator) and then written by the Eclipse generator
in the Eclipse project file. This way Eclipse can find the standard headers
(#7585)
Not sure CMakeSystemSpecificInformation.cmake is the best place to do this.
Alex
cmMakefile.cxx, but now in the platform files and are now valid for the
target platform, not the host platform.
New variables CMAKE_HOST_WIN32, CMAKE_HOST_UNIX, CMAKE_HOST_APPLE and
CMAKE_HOST_CYGWIN have been added in cmMakefile.cxx (...and have now to be
used in all cmake files which are executed before
CMakeSystemSpecificInformation.cmake is loaded). For compatibility the old
set is set to the new one in CMakeDetermineSystem.cmake and reset before the
system platform files are loaded, so custom language or compiler modules
which use these should still work.
Alex
CMAKE_SYSTEM_AND_C_COMPILER_INFO_FILE, CMAKE_SYSTEM_AND_CXX_COMPILER_INFO_FILE,
CMAKE_SYSTEM_AND_C_COMPILER_AND_PROCESSOR_INFO_FILE and CMAKE_SYSTEM_AND_CXX_COMPILER_AND_PROCESSOR_INFO_FILE
Instead of presetting these variables to arbitrary filenames, users should
set up CMAKE_SYSTEM_NAME and the compilers correctly and also create a
Platform/ directory so these files will all follow the official cmake style,
which should make it easier to understand and debug project which have their
own platform/toolchain support files.
-remove support for a suffix to MS crosscompilers, since this is not (yet)
supported by cmake and might confuse users
Alex
-add a RESULT_VARIABLE to INCLUDE()
-add CMAKE_TOOLCHAIN_FILE for specifiying your (potentially crosscompiling) toolchain
-have TRY_RUN() complain if you try to use it in crosscompiling mode (which were compiled but cannot run on this system)
-use CMAKE_EXECUTABLE_SUFFIX in TRY_RUN(), probably TRY_RUN won't be able to
run the executables if they have a different suffix because they are
probably crosscompiled, but nevertheless it should be able to find them
-make several cmake variables presettable by the user: CMAKE_C/CXX_COMPILER, CMAKE_C/CXX_OUTPUT_EXTENSION, CMAKE_SYSTEM_NAME, CMAKE_SYSTEM_INFO_FILE
-support prefix for GNU toolchains (arm-elf-gcc, arm-elf-ar, arm-elf-strip etc.)
-move ranlib on OSX from the file command to a command in executed in cmake_install.cmake
-add support for stripping during install in cmake_install.cmake
-split out cl.cmake from Windows-cl.cmake, first (very incomplete) step to support MS crosscompiling tools
-remove stdio.h from the simple C program which checks if the compiler works, since this may not exist for some embedded platforms
-create a new CMakeFindBinUtils.cmake which collects the search fro ar, ranlib, strip, ld, link, install_name_tool and other tools like these
-add support for CMAKE_FIND_ROOT_PATH for all FIND_XXX commands, which is a
list of directories which will be prepended to all search directories, right
now as a cmake variable, turning it into a global cmake property may need
some more work
-remove cmTestTestHandler::TryExecutable(), it's unused
-split cmFileCommand::HandleInstall() into slightly smaller functions
Alex
Brad King
Bill Hoffman
Alexander Neundorf
Andy Cedilnik
Sebastien Barre