eec93bce Allow OBJECT libraries to be installed, exported, and imported
93c89bc7 Genex: Allow TARGET_OBJECTS to be used everywhere
ac0cf7ff Genex: Reject TARGET_OBJECTS on non-object libraries earlier
8577978c Tests: ExportImport C code should use explicit (void) in prototypes
26cfd039 cmInstallTargetGenerator: Re-order GenerateScriptForConfig logic
25f3f22a cmGlobalGenerator: Add method to check if object file location is known
d596c550 cmGeneratorTarget: Add method to get the object file directory
930042f2 cmGeneratorTarget: Factor out a GetTargetObjectNames method
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !712
Drop hard-coded paths from this test. If we later need machine-specific
environment entries we can add dedicated infrastructure for it to be
configured locally.
Since `cmake --help` output now uses `[arch]` placeholders for the VS
generators, this test has been extracting invalid generator names.
Switch to using `cmake -E capabilities` to get a more robust listing of
the generators that does not depend on parsing human-readable help
output.
The `find_*` commands read search paths from both CMake variables
and from environment variables. Document how multiple values in
these variables should be separated.
Fixes: #16800
Teach install() and export() to handle the actual object files.
Disallow this on Xcode with multiple architectures because it
still cannot be cleanly supported there.
Co-Author: Brad King <brad.king@kitware.com>
Previously the `TARGET_OBJECTS` generator expression was limited
only to use in a buildsystem context so that Xcode's placeholders
in object file paths can be evaluated. Lift this restriction so
that the expression can at least be used in most settings.
Co-Author: Brad King <brad.king@kitware.com>
Move the diagnostic that rejects the TARGET_OBJECTS generator expression
in non-buildsystem context until after the check for whether the named
target is an object library. This order will makes more sense than the
previous order once TARGET_OBJECTS is allowed in non-buildsystem
context.
Add a `HasKnownObjectFileLocation` method returning whether we know the
exact location of object files produced by the native build system.
This is true everywhere except on Xcode when an architecture placeholder
is used.
ca697bfc cmGeneratorTarget: Drop obj libs from GetConfigCommonSourceFiles
e44a8d2c Xcode: Refactor loop over all sources
97cc29c7 VS: Teach generators how to mark per-config source files
2f6f6f0c Xcode: Use config-specific object library files on link lines
888c8af6 VS: List config-specific object library files on link lines
40aa6c05 cmGeneratorTarget: Add method to collect all sources for all configs
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !701
fee01194 VS: Add an environment variable for the Windows 10 kits directory
b80c6d12 VS: Refactor Win 10 Kits root detection to support multiple roots
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !696
Refactoring in commit 60307c5056 (cmGeneratorTarget: Replace source
classifier implementation, 2017-04-07) accidentally regressed support
for CMP0026's OLD behavior in the case of a source file written by
project code during the configure step after getting a LOCATION. We
should not perform full source classification until the generate step
because files written by the project's configure step may not exist yet.
Add special logic to support this case. Add a test case for it.
Reported-by: David Stoup <david.stoup@kitware.com>
