These modules are not meant to be included by user code, they are
only an internal implementation detail for CPack. Having them live
in the main Modules directory with documentation was misleading, so
they have been moved into Modules/Internal/CPack, and their
documentation has been stripped following its move into the new
"CPack Generators" section. No-op modules which contained only
documentation have been removed entirely.
The only module that hasn't been moved is CPackIFW, because it
contains user-facing macros which would be lost if it were moved.
So, the CPackIFW module has been updated with a note explaining what
needs to (eventually) happen.
The documentation for CPack generators previously lived in their
respective internal CMake modules. This setup was misleading,
because it implied that you should include the modules in your own
code, which is not the case. Moving the documentation into a
separate section does a better job of hiding the internal modules,
which are just an implementation detail. The generator documentation
has also been modified to remove any references to the module name.
The CPackIFW module is a special exception: since it has user-facing
macros, the documentation for these macros has been kept in the module
page, while all other documentation related to the IFW generator has
been moved into the new section.
To make it easier to find the new documentation, the old help pages
for the CPack*.cmake modules have not been deleted, but have been
replaced with a link to their respective help page in the new
documentation section.
The change in commit v3.12.0-rc1~202^2~1 (FindJPEG: Add multi config
support and associated docs, 2018-04-17) accidentally left out the
default jpeg library names from consideration for debug variants.
Upstream CURL provides imported target `CURL::libcurl`. Rename the
target added by `FindCURL` to match. We don't need compatibility with
the old name because it has never been in a CMake release (except a 3.12
release candidate).
Suggested-by: Jakub Zakrzewski <slither.jz@gmail.com>
Acked-by: Rolf Eike Beer <eike@sf-mail.de>
Fixes: #18091
Xcode 10 no longer populates `CURRENT_ARCH` with the current
architecture in shell scripts and instead uses `undefined_arch`.
Instead we must use `ARCHS`. It lists all architectures separated by
spaces.
Fixes: #18085
Fix a typo from commit 0bef9eb410 (UseSWIG: modernize module,
2018-01-29) that caused `UseSWIG` to ignore an eventually set property
`SWIG_MODLUE_NAME`.
Building multiple python modules using the mentioned property as
described in the docs could lead to an invalid, or even worse,
inconsistent `build.ninja` file. The reason is that the generated list
of support files was not unique. For each module the support file was
always named the same, namely `path/to/builddir/MODULENAME.py`.
66ea1a3795 LINK_OPTIONS: Add support of "LINKER:" prefix
c1f5a44b28 LINK_OPTIONS: Add new family of properties
8e28d2630a Makefile generator: link flags management refactoring
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Alex Turbov <i.zaufi@gmail.com>
Merge-request: !2033
Macro 'check_required_components' should be called even if there are no
components provided by package. This will make sure error is reported
in next cases:
find_package(Foo CONFIG REQUIRED oops) # 'oops' treated as component
find_package(Foo CONFIG REQUIRED COMPONENTS foo) # no components expected
Intel compilers define `__cpp_constexpr` to `200704` even in C++14 mode.
This indicates that the `cxx_relaxed_constexpr` feature is not
available. However, Intel 17 and above document support for it. In
commit v3.8.0~9^2 (Features: Update features for Intel C++ 17.0.2 on
UNIX, 2017-03-31) we added a special check for this case. Intel 17 and
19 work. However, Intel 18 does not seem to work and fails our test
case. Add a special case to disable the feature for Intel 18.
Generalize the fix in commit v3.11.0-rc4~8^2 (ExternalProject: Fix cache
generation when last args ends with "-NOTFOUND", 2018-03-10) to work for
any argument rather than just the last one.
ExternalProject can now successfully generate the cache file when any
(not only the last one) cache variable associated with either
`CMAKE_CACHE_ARGS` or `CMAKE_DEFAULT_CACHE_ARGS` configure step option
is set to a `<value>` ending with `-NOTFOUND`.
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 6.0.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
Moves `CMAKE_${lang}_COMPILER_PREDEFINES_COMMAND` from linux specific
[Modules/Platform/Linux-GNU.cmake](Modules/Platform/Linux-GNU.cmake) to
[Modules/Compiler/GNU.cmake](Modules/Compiler/GNU.cmake).
This enables compiler predefines generation (in AUTOMOC) on all
platforms that run gcc (and clang).
Add new `version=` parameter in the toolset setting to select the
version. Add variable `CMAKE_VS_PLATFORM_TOOLSET_VERSION` to hold the
version, if one is set (blank indicates default).
Fixes: #17549
The `<CMAKE_CUDA_LINK_FLAGS>` placeholder in CUDA rule variables comes
from the `<CMAKE_CXX_LINK_FLAGS>` placeholder from which the CUDA rule
variables were originally derived. It is not a public interface for
adding link flags so no projects should be using it. It is needed for
platform information modules to specify platform-specific link flags for
the language. None of our platform modules set it, so it is unused.
Furthermore, it is broken as currently implemented. Some of the
contexts in which it is used need `-Xlinker` and some do not.
Therefore it is not possible to use the placeholder at all.
Simply remove it for now. If some need for platform-specific CUDA link
flags arises a new solution will be needed.
Kyle Edwards