Just like the existing WindowsPhone and WindowsStore platform modules
for MSVC, just include the corresponding Windows platform modules.
MinGW tools (both with GCC and Clang) can be used for building for
Windows Store, even though it isn't a very common or simple setup.
Code added by commit v3.12.0-rc1~53^2 (FindLua: Search for lua.h using
more conventional paths, 2018-05-20) depends on `CMP0012` NEW behavior.
Set the policy explicitly for the scope of the FindLua module.
Fixes: #18142
This generator doesn't actually package the files. Instead, it
provides a metadata JSON file that can be used by external packaging
software to do its own packaging. This JSON file provides information
about the components, component groups, installation types, and CMake
projects.
The test code added by commit v3.12.0-rc1~411^2~1 (FindOpenMP: Verify in
test source that OMP library is linked, 2018-03-01) leaves an unused
variable warning. This breaks the check with `-Werror`. Remove the
variable and leave just the function call, which should still check that
the OMP library is linked.
Fixes: #18102
Ensure we use the `cmake` corresponding to the running `cpack`
even if it is not first in `PATH` or has had its name changed.
This was accidentally left out in commit v3.7.0-rc1~81^2 (CPack/RPM:
Generate source rpm (SRPM) packages on demand, 2016-09-19).
ae4a548302 FindJPEG: Drop ancient compatibility NATIVE_JPEG_* result variables
7876f329a9 FindJPEG: Add forgotten names of libraries for Debug configuration
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2159
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
