- The source-file signature of try_compile looks up the language
of the source file using the extension-to-language map so that
it knows what language to enable in the generated project.
- This map needs to be filled before loading a file specified by
CMAKE_USER_MAKE_RULES_OVERRIDE
CMAKE_USER_MAKE_RULES_OVERRIDE_<LANG>
so that the user file may call the try_compile() source-file
signature.
- It must still be re-filled after loading CMake<LANG>Information.cmake
in case the compiler- or platform-specific files added anything.
- See bug #7340.
ENH: -if no compiler has been found, don't test it, and also remove the compiler
information file again. This makes optionally enabling a language work
better.
Alex
- The rule hash should use only commands specified by the user.
- No make output (echo and progress) rules should be included.
- No outputs or dependencies need be included. The native build tool
will take care of them.
- In CMake 2.4 custom commands would not rebuild when rules changed.
- In CMake 2.6.0 custom commands have a dependency on build.make
which causes them to rebuild when changed, but also when any
source is added or removed. This is too often.
- We cannot have a per-rule file because Windows filesystems
do not deal well with lots of small files.
- Instead we add a persistent CMakeFiles/CMakeRuleHashes.txt file
at the top of the build tree that is updated during each
CMake Generate step. It records a hash of the build rule for
each file to be built. When the hash changes the file is
removed so that it will be rebuilt.
- Previously this was done implicitly by the check for a target
link language which checked all source full paths.
- The recent change to support computing a link language without
finding all the source files skipped the implicit check.
- This change adds an explicit check to find all source files.
- CMake 1.8 and below did not do the check but could get in
infinite loops due to the local generate step.
- CMake 2.0 added the check but failed to perform it in directories
with no targets (see bug #678).
- CMake 2.2 removed the local generate which fixed the problem but
did not remove the check.
- Between CMake 2.4 and 2.6.0rc6 the check was fixed to work even
when no targets appear in a directory (see bug #6923).
- Bottom line: the check is no longer needed.
- Cycles may be formed among static libraries
- Native build system should not have cycles in target deps
- Create cmComputeTargetDepends to analyze dependencies
- Identify conneced components and use them to fix deps
- Diagnose cycles containing non-STATIC targets
- Add debug mode property GLOBAL_DEPENDS_DEBUG_MODE
- Use results in cmGlobalGenerator as target direct depends
- Imported frameworks have the FRAMEWORK property set
- Added cmTarget::IsFrameworkOnApple method to simplify checks
- Also remove separate IMPORTED_ENABLE_EXPORTS property and just use ENABLE_EXPORTS since, like FRAMEWORK, it just represents the target type.
- Document FRAMEWORK keyword in INSTALL command.
- Updated IMPORTED_LOCATION property documentation for Frameworks
- Created cmExportFileGenerator hierarchy to implement export file generation
- Installed exports use per-config import files loaded by a central one.
- Include soname of shared libraries in import information
- Renamed PREFIX to NAMESPACE in INSTALL(EXPORT) and EXPORT() commands
- Move addition of CMAKE_INSTALL_PREFIX to destinations to install generators
- Import files compute the installation prefix relative to their location when loaded
- Add mapping of importer configurations to importee configurations
- Rename IMPORT targets to IMPORTED targets to distinguish from windows import libraries
- Scope IMPORTED targets within directories to isolate them
- Place all properties created by import files in the IMPORTED namespace
- Document INSTALL(EXPORT) and EXPORT() commands.
- Document IMPORTED signature of add_executable and add_library
- Enable finding of imported targets in cmComputeLinkDepends
- 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.
Configure() gets easier to overview
-improve the error message, now it also says in which directories and for
which targets the missing variables are used
-minor speedup: the include directories don't have to be checked per target,
per directory is enough
Alex
two-step priority (None or Prefered)
Current order: ASM 0, C 10, Fortran 20, CXX 30, Java 40
This is the same order as automake choses:
http://www.gnu.org/software/automake/manual/html_node/How-the-Linker-is-Chosen.html
This change should be backward compatible:
if there is a project using fortran and CXX, they had to set the
LINKER_LANGUAGE explicitely, otherwise cmake complained (but still generated
the project files). Explicitely setting the linker language still overrides
automatic detection.
If somebody has a custom language for cmake and the PREFERENCE starts with
"P", its changed to 100, which gives it preference over all other languages
(except the other custom languages which have also "Prefered"). "None" is
converted to 0.
Alex
something like this:
ENABLE_LANGUAGE(ASM-ATT)
IF(CMAKE_ASM-ATT_COMPILER_WORKS)
... do assembler stufff
ELSE(CMAKE_ASM-ATT_COMPILER_WORKS)
... fallback to generic C/C++
ENDIF(CMAKE_ASM-ATT_COMPILER_WORKS)
Alex
CMakeDetermineSystem.cmake, since CMAKE_SYSTEM_NAME might already be preset
when using cmake for cross compiling
use type STRING instead of FILEPATH since otherwise a strange filename was
generated
Alex
Bill Hoffman
Brad King
Alexander Neundorf
Ken Martin
David Cole