In each CMake<lang>Information.cmake file we use an _INCLUDED_FILE
variable to track whether a compiler information file has been loaded.
Reset this variable for each language.
This fixes Fortran under VS generators with the Intel plugin.
Previously the variable would be left set true from C and C++ and then
Fortran would not load old-style files like Platform/Windows-ifort.
Several platform-wide linker flag variables are defined in
Modules/Platform/<os>.cmake files for C and then copied by the
Modules/CMake<lang>Information.cmake file for each language.
We now use this approach for the variables
CMAKE_EXE_EXPORTS_${lang}_FLAG
CMAKE_SHARED_LIBRARY_SONAME_${lang}_FLAG
CMAKE_SHARED_LIBRARY_CREATE_${lang}_FLAGS
to avoid duplication for multiple languages in each platform file.
The commit "fix for bug 4772" added a work-around to CMakeCInformation
for platform config files that put compiler information in the system
file (like SunOS flags for GCC). This commit adds the same work-around
for CXX and Fortran. It is necessary to support enabling these
languages separately from C in other subdirectories.
The commit "Avoid (Unix|Windows)Paths.cmake multiple include" added
include blockers that prevent the files from multiple inclusion, so it
is safe to include the system information files from every language.
See issue #4772 and issue #9656.
This adds copyright/license notification blocks CMake's non-find
modules. Most of the modules had no notices at all. Some had notices
referring to the BSD license already. This commit normalizes existing
notices and adds missing notices.
This teaches the language configuration modules to load per-compiler
information for each language using the compiler id but no system name.
They look for modules named "Compiler/<id>-<lang>.cmake". Such modules
may specify compiler flags that do not depend on the platform.
Creation of archive libraries with the unix 'ar' tool should be done
incrementally when the number of object files is large. This avoids
problems with the command line getting too many arguments.
- Move runtime path ordering out of cmComputeLinkInformation
into its own class cmOrderRuntimeDirectories.
- Create an instance of cmOrderRuntimeDirectories for runtime
path ordering and another instance for dependent library
path ordering.
- Replace CMAKE_DEPENDENT_SHARED_LIBRARY_MODE with explicit
CMAKE_LINK_DEPENDENT_LIBRARY_FILES boolean.
- Create CMAKE_LINK_DEPENDENT_LIBRARY_DIRS boolean.
- Create variables to specify -rpath-link flags:
CMAKE_SHARED_LIBRARY_RPATH_LINK_<LANG>_FLAG
CMAKE_EXECUTABLE_RPATH_LINK_<LANG>_FLAG
- Enable -rpath-link flag on Linux and QNX.
- Documentation and error message updates
- This is purely an implementation improvement. No interface has changed.
- Create cmComputeLinkInformation class
- Move and re-implement logic from:
cmLocalGenerator::ComputeLinkInformation
cmOrderLinkDirectories
- Link libraries to targets with their full path (if it is known)
- Dirs specified with link_directories command still added with -L
- Make link type specific to library names without paths
(name libfoo.a without path becomes -Wl,-Bstatic -lfoo)
- Make directory ordering specific to a runtime path computation feature
(look for conflicting SONAMEs instead of library names)
- Implement proper rpath support on HP-UX and AIX.
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
second part copies the values from the cmake variables into internal maps.
So this can now be done after the compiler-specific information has been
loaded, which can now overwrite more settings.
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