f0e298ad Help: Add notes for topic 'vs14-generator'
5c105140 Tests: Simplify LoadCommand tests
b1cbd577 FindBoost: Add -vc140 mangling for VS 14
bdc7d9c8 VS14: Fix Cl and Link flag tables as previous versions
d96b3f68 VS14: Generate flag tables from MSBuild v140 tool files
65624c39 VS14: Add Visual Studio 14 generator (#14982)
8635ac23 Tests/Preprocess: Remove unnecessary VS version tests
24637979 cmTarget: Refactor ComputeLinkImplementation
7812d2a9 cmTarget: Pre-indent a block in ComputeLinkImplementation
f48d8bd6 cmTarget: Shorten a long line in ComputeLinkImplementation
7b0834e9 cmTarget: Refactor internal LinkImplementation map
b8651d97 cmTarget: Remove unnecessary 'mutable' markup
0192be51 cmTarget: De-duplicate link interface evaluation for $<LINK_ONLY>
6ead631b cmTarget: Teach GetLinkInterfaceLibraries to support $<LINK_ONLY>
b030a7f1 cmTarget: De-duplicate link interface genex code for $<LINK_ONLY>
1001490d cmTarget: Teach ExpandLinkItems how to support $<LINK_ONLY>
Apply the flag table fixes from:
commit 9c7f234c (VS: Fix /MANIFESTUAC:NO linker option mapping, 2014-05-07)
commit e8633e66 (VS: Fix /analyze:log flag mapping, 2014-04-01)
commit f2caf795 (VS: Fix /MAP:mapfile flag mapping, 2013-07-09)
to the VS 14 flag tables.
Run cmparseMSBuildXML.py on cl.xml, lib.xml, and link.xml to generate
our flag tables:
python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/V140/1033/cl.xml" > cmVS14CLFlagTable.h
python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/V140/1033/lib.xml" > cmVS14LibFlagTable.h
python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/V140/1033/link.xml" > cmVS14LinkFlagTable.h
Fix up the declaration names at the top of each file. Finally, teach
cmVisualStudio10TargetGenerator to select the version of the table
matching the version of VS.
Co-Author: Pawel Stopinski <diokhan@go2.pl>
Call the generator "Visual Studio 14" without any year because this
version of VS does not provide a year in the product name.
Copy cmGlobalVisualStudio12Generator to cmGlobalVisualStudio14Generator
and update version numbers accordingly. Add the VS14 enumeration value.
Teach the platform module Windows-MSVC to set MSVC14 and document the
variable. Teach module InstallRequiredSystemLibraries to look for the VS
14 runtime libraries.
Teach tests CheckCompilerRelatedVariables, VSExternalInclude, and
RunCMake.GeneratorToolset to treat VS 14 as they do VS 10, 11, and 12.
Co-Author: Pawel Stopinski <diokhan@go2.pl>
Since commit v3.0.0-rc1~374^2 (Refactor internal resource location APIs
and initialization, 2013-11-07) a bootstrap-built "cmake" tries to
reference "ctest" and "cpack" executables next to itself, which never
exist. Teach cmSystemTools::FindCMakeResources, when bootstrap-built,
to refer to the "ctest" and "cpack" executables in the location where
they will be built after "make".
f5c18c9c cmTarget: Drop GetDirectLinkLibraries methods
281eb3d8 cmTarget: Improve HaveBuildTreeRPATH implementation
d912220e cmTarget: Lookup targets in LinkInterface and LinkImplementation
edce4351 cmExportFileGenerator: Make SetImportLinkProperty a template
097be413 cmTarget: Add GetUtilityItems to get target ordering dependencies
4dad5fd2 cmTarget: Add cmLinkItem to refer to a target by name and pointer
a2723442 Fix scope of transitive target name lookups
069d60fe cmTarget: Add method to lookup other targets in a target's scope
47ab3ca6 cmTarget: Constify GetLinkImplementationClosure results
9f3ed029 cmTarget: Constify GetTransitivePropertyTargets results
6f0951af cmTarget: Drop 'head' target from GetImportInfo
0dc9e88d cmTarget: Remove 'head' argument from GetLinkImplementation
4ac72455 cmTarget: Drop 'head' argument from GetLinkClosure
bcdb7ff9 cmTarget: Remove 'head' argument from GetLinkerLanguage
bd9b667b cmComputeLinkInformation: Remove 'head' argument
06328dd5 cmTarget: Remove 'head' argument from GetLinkInformation
...
The ctest launcher code did not respect the number of errors and
warnings limits. Limit the number of launcher report fragments that we
report in the final submission.
Use LinkImplementationPropertyEntries directly instead of asking
GetProperty to construct a string for LINK_LIBRARIES. This gives us
access to the entry backtraces.
If ComputeLinkImplementationLanguages were ever to cause
GetLinkImplementationLibraries to be invoked then a LinkImplMap entry
may appear in the middle of computing it in GetLinkInformation. Instead
create the map entry up front and store in it boolean values indicating
which pieces of the LinkImplementation structure have been populated.
This approach leads to shorter code that is easier to follow too.
Members of the cmTargetInternals structure do not need to be made
'mutable' even to cache data because there is no reason for the
internal methods to be 'const'.
Teach GetTransitivePropertyTargets to use the GetLinkInterfaceLibraries
method with usage_requirements_only==true instead of evaluating the
INTERFACE_LINK_LIBRARIES property directly. This avoids duplicate
evaluations and makes use of the caching done by
GetLinkInterfaceLibraries.
Add a 'usage_requirements_only' parameter to GetLinkInterfaceLibraries
and supporting internal APIs to pass through to ExpandLinkItems so it
knows whether to use SetTransitivePropertiesOnly while evaluating
generator expressions.
Simplify the implementation of GetTransitivePropertyTargets by using
ExpandLinkItems with usage_requirements_only==true to evaluate the
generator expressions in the link interface for us.
Add a 'usage_requirements_only' parameter to ExpandLinkItems so that it
knows whether to use SetTransitivePropertiesOnly while evaluating
generator expressions. Update existing call sites to pass 'false' since
they are for linking and not usage requirements.
Since commit 6557382d (stringapi: Use strings for program
paths, 2014-02-24), cmGlobalGenerator::GenerateBuildCommand
takes the make program path as a std::string. Fix the lookup
in cmCPackGenerator::InstallProjectViaInstallCMakeProjects to
use GetSafeDefinition for CMAKE_MAKE_PROGRAM to avoid possible
construction of std::string from a NULL.
Reported-by: Richard Wirth <richard@califax.de>
Installing large directories, e.g., the output of a doxygen run, prints
one line per file resulting in too much noise in the build output. Add
an option to the install(DIRECTORY) command to not print anything upon
make install.
Extend the RunCMake.install test with cases covering MESSAGE_NEVER
behavior of the install(DIRECTORY) command.
Suggested-by: Stefan Eilemann <Stefan.Eilemann@epfl.ch>
Create a variable to allow users to control which installation
messages are printed. In particular, provide a "LAZY" setting
that prints "Installing" messages but not "Up-to-date" messages.
This is desirable for incremental re-installations.
Suggested-by: J Decker <d3ck0r@gmail.com>
Create a cmInstallGenerator::MessageLevel enumeration for future use in
specifying install message verbosity. Thread values of the type through
constructors and save the value as a member of cmInstallGenerator.
Use only a "MessageDefault" value for now.
Create options "MESSAGE_ALWAYS", "MESSAGE_LAZY", and "MESSAGE_NEVER" to
specify whether to print the "Installing" and "Up-to-date" messages.
Extend the RunCMake.file test with cases covering these options.
Teach cmFileCopier::InstallDirectory to detect whether the destination
directory exists. If so, report it as "Up-to-date" instead of
"Installing". This resolves message asymmetry with file installations.
Extend the RunCMake.file and RunCMake.install tests to check the
installation output on both the first and second run.
Suggested-by: J Decker <d3ck0r@gmail.com>
When installing a DIRECTORY, do not pre-create the DESTINATION. The
cmFileCopier::InstallDirectory method will create the directory anyway.
Give it a chance to detect whether the directory already exists or not.
Extend the cmake command-line interface to support
cmake -E env [--unset=NAME]... [NAME=VALUE]... COMMAND [ARG]...
This will be useful to run processes with modified environments
without using a shell or a full "cmake -P" script to wrap it.
Extend the RunCMake.CommandLine test to cover success and failure cases.
Inspired-by: Jonathan Bohren <jbo@jhu.edu>
From the GCC 4.9 release notes for Fortran:
https://gcc.gnu.org/gcc-4.9/changes.html
"Module files: The version of the module files (.mod) has been
incremented; additionally, module files are now compressed."
Teach cmDependsFortran::ModulesDiffer to look for the gzip magic numbers
at the beginning of the module file. If found, assume the module was
produced by gfortran >= 4.9. The modules do not appear to contain the
date as earlier versions did so we can compare the content directly
and do not actually need to decompress.
Since commit 84fdc9921 (stringapi: Pass configuration names as strings,
2014-02-09), it is not safe to use GetDefinition("CMAKE_BUILD_TYPE")
without checking the return value. Use GetSafeDefinition instead so
that a missing definition is treated as an empty string like code paths
did prior to the above commit.
Reported-by: Richard Wirth <richard@califax.de>
Use GetLinkImplementationLibraries instead of GetDirectLinkLibraries
because it tells us whether there will be any libraries to link after
evaluating generator expressions. Also GetDirectLinkLibraries will be
dropped soon.
Instead of storing just the string names in these structures, lookup any
target associated with each item and store its cmTarget pointer. Use
the cmLinkItem class to hold the name and pointer together. Update
client sites to use the pre-stored lookup result instead of looking up
the target name again.
Create a cmTarget::LookupLinkItems helper method to handle the lookup.
Since lookups are now moving from cmComputeLinkDepends::AddLinkEntries
to cmTarget::LookupLinkItems, move use of CheckCMP0004 to the latter.
This drops use of CheckCMP0004 from entries added for _LIB_DEPENDS
variables by cmComputeLinkDepends::AddVarLinkEntries, but I do not
think that use was intentional originally anyway.
