Eliminate callers of cmMakefile::GetIncludeDirectories.
All callers of GetIncludeDirectories should go through the local generator
object.
Only the local generator calls cmTarget::GetIncludeDirectories directly.
Teach the Windows-GNU.cmake platform file to look for Visual Studio
tools matching the target ABI. Add an extra step to the link command
for shared libraries and executables that export symbols and on which a
new GNUtoMS property is set (initialized by the CMAKE_GNUtoMS option).
Tell the GNU linker to output a module definition (.def) file listing
exported symbols in addition to the GNU-format import library (.dll.a).
Pass the .def file to the MS "lib" tool to construct a MS-format DLL
import library (.lib).
Teach the install(TARGETS) command to install the MS import library next
to the GNU one. Teach the install(EXPORT) and export() command to set
the IMPORTED_IMPLIB property pointing at the import library to use the
import library matching the tools in the importing project.
Define a "Fortran_FORMAT" target and source file property. Initialize
the target property from a "CMAKE_Fortran_FORMAT" variable. Interpret
values "FIXED" and "FREE" to indicate the source file format. Append
corresponding flags to the compiler command line.
Older versions of GCC, the HP compiler, and the SGI MIPSpro compiler do
not like the use of make_pair in this case and the conversions it
requires:
a value of type "const char *" cannot be used to initialize an entity
of type "char [1]"
/usr/include/g++-3/stl_pair.h:68: assignment of read-only location
Instead use a map lookup pattern already used throughout the rest of our
source tree.
Create platform option CMAKE_<lang>_USE_RESPONSE_FILE_FOR_INCLUDES to
enable use of response files for passing the list of include directories
to compiler command lines.
Move the GetDefineFlags call from cmLocalGenerator::GetIncludeFlags to
all call sites so that the method exclusively constructs a string of
include search path flags.
Commit 60cd72d0 (Cleaned up generation of symbolic rules, 2006-02-15)
incorrectly made these Makefile targets .PHONY even though the build
rule touches an actual file. Correct it so that the copy_f90_mod and
touch steps do not happen on every "make".
Commit 34e1ac24 (Create Fortran info variables for .mod behavior,
2010-11-12) incorrectly taught GetFortranModuleDirectory to return a
relative path. We really want to use "." as the module directory only
as a workaround for compilers that do not do so by default. Therefore
we need this default only when generating the compiler command line and
not when scanning dependencies.
Revert the previous change to GetFortranModuleDirectory and apply the
change only at one of its call sites.
Define CMAKE_Fortran_MODDIR_DEFAULT and CMAKE_Fortran_MODOUT_FLAG
variables to help some Fortran compilers generate .mod files in the
current working directory.
Tru64's make(1) resolves relative paths in "include" directives with
respect to the includer. This is inconsistent with all other known make
tools. Note that this make tool treats the path literally so we cannot
use our standard FULL path code which escapes spaces. Instead qualify
the paths with $(CMAKE_BINARY_DIR) to avoid the problem.
Create platform variable "CMAKE_<LANG>_RESPONSE_FILE_LINK_FLAG" to
specify an alternative to "@" for referencing response files. It
applies specifically to response files with linker options.
See issue #10401.
Response files are parsed by tools, not by shells. We teach
cmLocalGenerator::Convert() a new "RESPONSE" output format and use it
for objects listed in response files. It does not do special slash or
MSYS root translation like the "SHELL" format does. This is necessary
for GNU tools on Windows to understand response file content.
See issue #10401.
The CMAKE_OSX_ARCHITECTURES variable works only as a global setting.
This commit defines target properties
OSX_ARCHITECTURES
OSX_ARCHITECTURES_<CONFIG>
to specify OS X architectures on a per-target and per-configuration
basis. See issue #8725.
This commit creates target and directory properties to enable the Intel
interprocedural optimization support on Linux. Enabling it adds the
compiler option '-ipo' and uses 'xiar' to create archives.
See issue #9615.
This creates cmTarget::GetFeature and cmMakefile::GetFeature methods to
query "build feature" properties. These methods handle local-to-global
scope and per-configuration property lookup. Specific build features
will be defined later.
We create cmMakefileTargetGenerator::AddFeatureFlags to consolidate
addition of language flags. Currently it just adds the flags from
generic per-language flag variables (AddLanguageFlags).
When building through NMake with VS 6, the module definition file must
be passed without spaces in the path. This is because 'cl -link' does
not escape the spaces when passing the value on to the linker.
We recognize .def source files and map them to the /DEF:<file> option in
the MSVC tools. Previously this worked only for shared libraries. This
commit cleans up the implementation and makes it work for executables
too. See issue #9613.
This converts the CMake license to a pure 3-clause OSI-approved BSD
License. We drop the previous license clause requiring modified
versions to be plainly marked. We also update the CMake copyright to
cover the full development time range.
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 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 cleans up the Makefile generator's progress rule code. Instead of
keeping every cmMakefileTargetGenerator instance alive to generate
progress, we keep only the information necessary in a single table.
This approach keeps most of the code in cmGlobalUnixMakefileGenerator3,
thus simplifying its public interface.
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 creates global property RULE_PROGRESS which can be set to disbale
per-rule progress reporting. On Windows, progress reports may cause a
noticable delay due to the cost of starting an extra process. This
feature will allow scripted builds to avoid the cost since they do not
need detailed progress anyway. See issue #8726.
The <target>_EXPORTS macro defined for object files when built in a
shared library <target> should be put in the <DEFINES> make rule
replacement and not <FLAGS>. Also, it should honor the platform
variable CMAKE_<LANG>_DEFINE_FLAG. See issue #8107.
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.
The recent change to avoid expanding rule variables in informational and
'cd' commands broke the logical order in generation of preprocess and
assembly rules. This corrects the order.
Previously the makefile generator would expand rule variables even on
its progress and echo commands for object compilation rules (but not for
link rules). This fixes the implementation to only expand rule
variables on user-specified rules.
This simplifies computation of custom command rule hashes to hash
content exactly chosen as the custom commands are generated.
Unfortunately this will change the hashes of existing build trees from
earlier CMake versions, but this is not a big deal. The change is
necessary so that in the future we can make optional adjustments to
custom command lines at generate time without changing the hashes every
time the option is changed.
Stephen Kelly
Brad King
Manuel Klimek
Alex Neundorf