Some vendor tools convert PDB file names given on the command line to
lower-case before creating the file. When CMake places a mixed-case PDB
file name into the build system, the file does not exist the first time
and it is written with mixed case. After the first build though the
native tool has created a lower-case version of the file. If CMake does
CollapseFullPath again, the file exists so the actual-case lookup gets
the lower-case name. This causes the build files to change so the
project rebuilds.
The solution is to avoid calling CollapseFullPath for files generated by
the build. In the case of PDB files we already construct them from
paths that have been collapsed, so we can just skip the call altogether.
See issue #9350.
This passes the build configuration to most GetLinkerLanguage calls. In
the future the linker language will account for targets linked in each
configuration.
This method previously required the global generator to be passed, but
that was left from before cmTarget had its Makefile member. Now the
global generator can be retrieved automatically, so we can drop the
method argument.
This teaches the makefile generators to always pass the configuration
name to the cmTarget::GetDirectory method. Later this will allow
per-configuration target output directories, and it cleans up use of the
current API.
This member stores the build configuration for which Makefiles are being
generated. It saves repeated lookup of the equivalent member from
cmLocalUnixMakefileGenerator3, making code shorter and more readable.
This creates global property RULE_MESSAGES which can be set to disbale
per-rule progress and action reporting. On Windows, these reports may
cause a noticable delay due to the cost of starting extra processes.
This feature will allow scripted builds to avoid the cost since they do
not need detailed information anyway. This replaces the RULE_PROGRESS
property created earlier as it is more complete. See issue #8726.
This defines global, directory, and target properties
RULE_LAUNCH_COMPILE, RULE_LAUNCH_LINK, and RULE_LAUNCH_CUSTOM. Their
values specify 'launcher' command lines which are prefixed to compile,
link, and custom build rules by Makefile generators.
This gives the cmTarget instance for which custom command rules are
being generated to cmLocalUnixMakefileGenerator3::AppendCustomCommands.
It will be useful in the future.
A previous change accidentally added the MacOS content directory and
Info.plist files created for MACOSX_BUNDLE executables to the list of
CMake input files. This causes CMake to re-generate the project too
often. These items should be added to the list of CMake output files.
Previously generation of object file lists for linker and cleaning
command lines was duplicated for library and executable target
generators. This combines the implementations.
These changes refactor cmLocalGenerator methods Convert and
ConvertToOutputForExisting to support references inside the build tree
using relative paths. After this commit, all tests pass with Makefile
generators when relative paths are enabled by default. See issue #7779.
- Use a response file when enabled by
CMAKE_<LANG>_USE_RESPONSE_FILE_FOR_OBJECTS
- Enable for C and CXX with cl (MSVC)
- Enable for Fortran with ifort (Intel Fortran)
- Fixes repeated rebuild of bundles by Makefile generators
- Add special rules to copy sources to their
MACOSX_PACKAGE_LOCATION bundle directory
- Remove MacOSX_Content language hack
- Remove EXTRA_CONTENT property
- Remove MACOSX_CONTENT
- Remove corresponding special cases in object names
- 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
Brad King
David Cole
Bill Hoffman
Andy Cedilnik
Ken Martin