Implement a Visitor to hold the sequence of source file tests
for populating outputs. Use VS 6 and 7 workaround from Brad
King for lack of partial template specialization and function
template specialization capabilities.
This will make it possible to use context dependent generator
expressions to determine the sources of a target.
The callers already skip non-targets, so unify the target search.
Change supporting functions to accept a container of targets instead
of strings where possible.
Most callers already have a std::string, on which they called c_str() to pass it
into these methods, which internally converted it back to std::string. Pass a
std::string directly to these methods now, avoiding all these conversions.
Those methods that only pass in a const char* will get the conversion to
std::string now only once.
Direct users of IMPORTED targets treat INTERFACE_INCLUDE_DIRECTORIES
as SYSTEM, after commit a63fcbcb (Always consider includes from IMPORTED
targets to be SYSTEM., 2013-08-29). It was intended that transitive
use of an IMPORTED target would have the same behavior, but that
did not work. The implementation processed only direct dependencies
in cmTarget::FinalizeSystemIncludeDirectories.
Implement transitive evaluation of dependencies by traversing the
link interface of each target in the link implementation.
Define a custom ordering functor to deterministically and strictly
order the cmTarget* key. Otherwise the order would be dependent on
runtime pointer values, which breaks assumptions of some generators.
The functor orders first by target name, and then by directory. Multiple
global targets may have the same name, such as edit_cache, but their
directory differentiates them.
638843a Remove the Location member from cmTarget.
90ef1cf Move GenerateTargetManifest to cmGeneratorTarget.
25f1df3 Split CreateGeneratorTargets into two methods.
Unlike other target properties, this does not have a corresponding
non-INTERFACE variant.
This allows propagation of system attribute on include directories
from link dependents.
Entries from the cmMakefile are processed and maintained similarly
to other include directories. The include_directories(SYSTEM)
signature affects all following targets, and all prior targets
in the same makefile.
Add support to maintain designer functionality for Visual Studio C++
Windows Forms projects. Also add a test project showing how to use
the CMakeLists.txt file and, when successfully configured, will allow
use of the designer for the included form.
Following from the discussion here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=5170
(Re: Generator expressisons in target properties, 26 Oct 12:10)
we can't split cmTarget API for linking into cmGeneratorTarget. In
the future we will probably also need to move the include and compile
definitions API back to cmTarget so that it can be used by export().
Commit 08cb4fa4 (Process generator expressions in the
INCLUDE_DIRECTORIES property, 2012-09-18) contained an incorrect
assumption that CMAKE_BUILD_TYPE was set on the makefile for each
generated configuration in multi-config generators. Fix that by making
the GetIncludeDirectories API depend on the config.
This reverts commit 987e12e2f9.
GenerateTargetManifest is called by the global generator before it
creates the generator targets, so we can't move it to cmGeneratorTarget
yet.
Header files listed in a target's PUBLIC_HEADER or similar properties
are marked as OS X Framework content. Refactoring performed by
commit 11d9b211 (Add cmGeneratorTarget to represent a target during generation, 2012-03-07)
commit 45c2f932 (Simplify cmMakefileTargetGenerator using cmGeneratorTarget, 2012-03-07)
commit 328c0f65 (Simplify cmVisualStudio10TargetGenerator source classification, 2012-03-19)
and related commits accidentally removed such files from treatment as
normal header files by the VS generator (generators other than Makefiles
and Xcode). Move handling of such files out of cmGeneratorTarget and
back to cmMakefileTargetGenerator. The central cmGeneratorTarget
classification will always treat them as header or extra sources.
Commit 328c0f65 (Simplify cmVisualStudio10TargetGenerator source
classification, 2012-03-19) introduced the first use of source
classification from cmGeneratorTarget (which originated as Makefile
generator logic) in a Visual Studio generator for handling of header
files. Fix classification of header files to match known header
extensions instead of only the HEADER_FILE_ONLY property. Make it
consistent with the "Header Files" source group.
Refactoring by commit 11d9b211 (Add cmGeneratorTarget to represent a
target during generation, 2012-03-07) and commit 45c2f932 (Simplify
cmMakefileTargetGenerator using cmGeneratorTarget, 2012-03-07) preserved
behavior introduced by commit 7740ccd1 (some cleanup of the makefile
generator, 2006-02-14) that favored the IgnoreFile extension test over
the availability of a known compilation language associated with a
source file. If a source is not marked as HEADER_FILE_ONLY and has a
known language extension or an explicit LANGUAGE property it should be
treated as that language. The LANGUAGE source file property
documentation says so.
Stephen Kelly
Rolf Eike Beer
Brad King
Nils Gladitz
John Farrier