Code extracted from:
https://gitlab.kitware.com/utils/kwsys.git
at commit 9f6ffaff4ed7b639b3523b43f41e70f75271f0cc (master).
Upstream Shortlog
-----------------
Brad King (3):
e71a3406 Encoding: Add ToWindowsExtendedPath function
41b8603c SystemTools: Use Encoding::ToWindowsExtendedPath
edd8b5e0 FStream: Open files on Windows using UNC path
Chuck Atkins (1):
0c4e58ec Silence warnings from newer CMake versions from CMP0048
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>
Add a `FILES_FROM_DIR` option to install a specific set of files
specified relative to a given directory and preserve their layout
in the destination. Currently we intend to use this internally
to implement other things so we don't provide an `install()`
porcelain or documentation yet.
Call sites such as those in the VS global generator that are used only
to reject per-config sources will now allow per-config object library
objects. The corresponding generators have already been taught to deal
with per-config object library files. Remaining call sites do not need
object library files anyway.
This will later allow `$<TARGET_OBJECTS:...>` generator expressions to
evaluate to values that vary by configuration (e.g. because each
configuration has its own object files).
Add internal infrastructure for looping over all sources for all
configurations and generating each source with exclusion marks
for configurations in which they do not participate. This does
not yet make per-config sources available in general but does
set up some of the needed infrastructure.
Unfortunately doing this cleanly will require major refactoring of both
the VS 7-9 generators and the VS 10+ generators (for separate reasons).
Instead add some extra internal structures to carry information where we
need it.
We can do this only with Xcode 5 and above where we list the object
library files in the per-config link line value. On older Xcode
versions we list the object files as sources so that dependencies work
correctly, but that does not allow per-config objects. (Xcode may allow
per-config source exclusion but only by base name.)
