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.)
Multi-config generators like VS and Xcode need to loop over all the
source files first and then handle per-config information within
each one. Teach cmGeneratorTarget to provide such a view.
229abfc8 cmGeneratorTarget: Drop unused UseObjectLibraries method
63fbf587 Xcode: Inline relevant parts of UseObjectLibraries
1afacebe Xcode: Do not add Object Libraries source group on Xcode >= 5
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !698
7f8b93ab CheckSymbolExists: Document that intrinsics may not be detected
91233d56 CheckSymbolExists: Format documentation
b416d3e6 CheckSymbolExists: Convert docs to bracket comment syntax
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !695
1d829c86 Use quotes for non-system includes
26ee9e42 CPack: drop CPack prefix for includes
5afac50f cmConfigure: Ensure separate include block in headers
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !691
Define a `CMAKE_WINDOWS_KITS_10_DIR` environment variable to allow
users to tell CMake about a custom Windows 10 SDK directory. We
choose to make this an environment variable rather than a CMake
variable or cache entry because:
* Using a custom directory also requires custom external MSBuild
configuration. Therefore users are already configuring a
custom environment.
* The custom directory must be set consistently in all parts of
a build including nested projects. An environment variable
avoids requiring users to thread the setting into nested builds.
Fixes: #16743
8c346bbc Xcode: Compute a concrete object file arch dir if possible
5f4e26df Xcode: Refactor object directory name computation
5b29fd6d Xcode: Refactor internal architecture list construction
b1eb493c cmGlobalGenerator: Abort generation earlier on export() error
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !688
Make sure that `#include <cmConfigure.h>` is followed by an empty line
in header files. This is necessary to make sure that changing <> to ""
does not affect the include ordering of clang-format.
Automate with:
git grep -l '#include <cmConfigure.h>' | grep -v '.cxx$' \
| xargs sed -i '/#include <cmConfigure.h>/ { N; N; s/\n\{1,2\}/\n\n/ }'
It is quite often the project description has used in a real world software.
Examples include:
* part of a help screen of the application
* builtin resources (`*.rc` files, data for "About" dialog of a GUI app, & etc)
* most generators for CPack can use it
* it could be used by documentary software (Doxygen, Sphinx) which is usually
integrated to CMake based projects via `add_custom_target()`
Now `project()` call learned an optional `DESCRIPTION` parameter with a
short string describing a project. Being specified, it would set the
`PROJECT_DESCRIPTION` variable which could be used in `configure_file()`
or whatever user wants. Also `PROJECT_DESCRIPTION` is a default value
for `CPACK_PACKAGE_DESCRIPTION_SUMMARY`.