Since support for generator expressions was added to OUTPUT_NAME it is
possible for project code to cause recursion in this method by using a
$<TARGET_FILE> genex. Detect and reject such cases.
6d8a125e cmQtAutoGenerators: Prefer a generator to access global generator.
5f66900e cmGlobalGenerator: Port Find API to cmMakefile.
c5b8841f cmGlobalGenerator: Create global targets from cmMakefiles.
8f75ea3b cmGlobalGenerator: Port global target creation to cmMakefile.
56f0540b cmGlobalGenerator: Port Configure-time check to cmMakefile.
19b546ef cmGlobalGenerator: Base final target property computation on Makefiles.
f8be9ba9 cmGlobalGenerator: Base progress on Makefiles, not LocalGenerators.
bc1097e3 cmExportLibraryDependenciesCommand: Port to cmMakefile.
204aecdf cmGlobalGenerator: Port configure-time code to cmMakefile.
3dd6f0a5 cmake: Port configure-time code to cmMakefile.
73e4df99 cmGlobalGenerator: Store a container of cmMakefiles.
19369937 cmGeneratorTarget: Port internal type to cmGeneratorTarget.
32f131b0 cmGeneratorTarget: Prefer the local generator to access the global.
29886ce7 cmTarget: Use a simpler delete algorithm.
197f4de1 cmTarget: Split storage of compile definitions from genexes.
44e071ae cmTarget: Split storage of compile features from genexes.
772ecef4 cmTarget: Split storage of compile options from genexes.
1f54bc1c cmTarget: Split storage of include directories from genexes.
7568199b cmTarget: Request only the link libraries where needed.
10040601 cmLinkImplementationLibraries: Move to namespace scope.
d9da6ee2 cmLinkItem: Split to separate file.
27252b24 cmComputeLinkInformation: Simplify generator object access.
The storage of a pointer means that the ownership and lifetime are
externally determined, which is harder to reason about. It also imposes
API constraints, requiring APIs to return references to backtraces.
This pointer storage was introduced in commit v3.1.0-rc1~425^2~3 (genex:
remove the need for backtraces, 2014-05-23). As backtraces are now cheap
to copy around, just do that instead.
XAML files are by default of type Page in the vcxproj and can be
overriden by setting the VS_XAML_TYPE property. The .cpp and .h file
of the same name are automatically added as depending on the XAML file.
New VSXaml test builds a basic XAML WindowsStore 8.1 app with VS2013.
Custom command path normalization added in commit v3.1.0-rc1~471^2
(add_custom_command: Normalize OUTPUT and DEPENDS paths, 2014-05-28)
broke use of OBJECT_DEPENDS to bring in custom commands because the
latter paths were not normalized too. Normalize them and add a test
case.
Reported-by: Daniel v. Gerpen
The evaluation files must be known before cmTargetTraceDependencies
attempts to find them, but we must actually generate the files after
cmTargetTraceDependencies, as that can add to target SOURCES. The
limitation is that the generated output name must not depend on the
SOURCES of a target if the generated file is used by that target.
Mark the output files as GENERATED so that trace dependencies does
not expect them to already exist in the filesystem.
Move the invokation of ForceLinkerLanguage in the Generate logic
to after the generated file names are known. ForceLinkerLanguage
tries to determine the sources of a target (in order to determine
an already-known language) and otherwise fails to get information
about the generated file.
Test that the output of file(GENERATE) can be used as a target source
file and that accessing the target SOURCES in the name of the output
file is an error. Accessing the TARGET_OBJECTS would be a similar
error if it was legal to use that generator expression in this
context. That is not currently possible and is a different error
condition, so test the current error output as a reminder to change
the expected output if that becomes possible in the future. Test
that generated rule files resulting from cmTargetTraceDependencies
appear in the SOURCES generated in the output file.
Teach cmGeneratorTarget to classify .pfx files as package
certificate key files. Teach cmVisualStudio10TargetGenerator
to write them as PackageCertificateKeyFile in .vcxproj files.
Inspired-by: Minmin Gong <minmin.gong@gmail.com>
Teach cmGeneratorTarget to extract .appxmanifest sources separately.
Teach cmVisualStudio10TargetGenerator to write them with the
AppxManifest tool in .vcxproj files. This will allow us to detect
whether the project provides an application manfiest explicitly.
Since commit v3.0.0-rc1~174^2~1 (cmTarget: Fix system include annotation
propagation, 2014-01-01) the cmGeneratorTarget::IsSystemIncludeDirectory
method needs to collect all targets that might provide
INTERFACE_(|SYSTEM)_INCLUDE_DIRECTORIES for the current target. We now
have cmTarget::GetLinkImplementationClosure to provide this, so use it.
Loosen this restriction on OBJECT libraries to allow source files of any
name to be generated by custom commands or listed for reference in IDE
projects so long as they would not affect linking of a normal library.
Update the rejection message to be more specific about the looser
restriction.
Extend the ObjectLibrary test to cover a ".cmake" file generated by a
custom command in an OBJECT library.
Create a cmLinkImplItem class derived from cmLinkItem so more
information can be added to link implementation entries than link
interface entries. Convert the LinkImplementation Libraries member to
hold it. Update client sites accordingly.
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.
In cmTarget, cmGeneratorTarget, and cmGeneratorExpressionEvaluator, fix
target name lookups to occur in the cmMakefile context of the target
that referenced the name, not the current 'head' target. The context
matters for imported targets because they are directory-scoped instead
of globally unique. We already do this in cmComputeLinkDepends and
cmComputeTargetDepends.
Extend the InterfaceLibrary test with an example covering this behavior.
Many of the 'head' arguments added by commit v2.8.11~289^2~1 (Make
linking APIs aware of 'head' target, 2013-01-04) turned out not to be
needed. The "link implementation" of a target never needs to be
computed with anything but itself as the 'head' target (except for
CMP0022 OLD behavior because then it is the link interface).
Remove the unused 'head' target paths. Add "internal" versions of
cmTarget::GetDirectLinkLibraries and GetLinkImplementationLibraries
to support the CMP0022 OLD behavior without otherwise exposing the
'head' target option of these methods.
Stephen Kelly
Brad King
Gregor Jasny
Felix Geyer
Robert Goulet
Gilles Khouzam
Nils Gladitz
Ben Boeckel