| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
`${CMAKE_COMMAND} -E` subcommands are cross-platform replacements.
Fixes: #24263
|
|
|
|
|
|
| |
Both modules have actually been removed entirely, they exist
in the Help directory only as "This module used to exist"
placeholders.
|
|
|
|
|
| |
OpenSP has not seen a release in seventeen years, so is unlikely to ever
provide a CMake package configuration file. Add a find module instead.
|
|
|
|
|
|
|
| |
Complement the several existing `FindSDL_*` modules.
Follow the pattern of the existing `FindSDL_mixer` module.
Fixes: #12004
|
|
|
|
|
|
| |
This CPack generator has been deprecated since commit 7bf187499f
(CPack: Deprecate PackageMaker generator, 2020-01-31).
Fixes: #23344
|
| |
|
|
|
|
| |
Document that one can call `set_property` directly instead.
|
|\ |
|
| |
| |
| |
| |
| |
| | |
See justification in the policy documentation.
Closes: #17842
|
| |
| |
| |
| |
| | |
The module has been deprecated since commit 306a1ba960
(Modules/Documentation: remove, 2020-04-16, v3.18.0-rc1~290^2).
|
| |
| |
| |
| |
| |
| |
| |
| | |
In commit cb28d9af1f (UseJava: Move helper scripts to subdirectory,
2020-11-12) we removed modules that were not meant to be documented
publicly. In order to keep links from older versions on `cmake.org` to
the "latest" documentation working for those modules, add placeholder
documents describing the change.
|
| |
| |
| |
| | |
Also, exclude them from the help module index.
|
|/ |
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes: #15934
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add entries in Modules and Modules/Platform to support
Objective-C++ compiler determination and identification.
Add Modules to check Objective-C++ compiler flags, source
compilations, program checks, etc...
Use OBJCXX as the designator of the language, eg:
project(foo OBJCXX)
Add various tests for Objective-C++ language features. Add
tests to preserve C++ handling of .M and .mm files when
Objective-C++ is not a configured language.
Co-authored-by: Cristian Adam <cristian.adam@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add entries in Modules and Modules/Platform to support
Objective-C compiler determination and identification.
Add Modules to check Objective-C compiler flags, source
compilations, program checks, etc...
Use OBJC as the designator of the language, eg:
project(foo OBJC)
Add various tests for Objective-C language features. Add
tests to preserve C++ handling of .m and .mm files when
OBJC is not a configured language.
Co-Authored-By: Cristian Adam <cristian.adam@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The `FindOctave` module added by commit 170bcb6fdc (FindOctave: Add
module to find GNU octave, 2018-11-17, v3.14.0-rc1~283^2) has a few
problems in its implementation that need to be worked out before the
module can be included in a CMake release. These were missed during
review. Remove the module for now. It can be restored later with a
fresh review.
Issue: #18991
|
|
|
|
|
| |
Add a Fortran equivalent to the existing `Check{C,CXX}SourceRuns`
modules.
|
|
|
|
| |
Fixes: #18700
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
0f5c1b404b find_package(): Add policy to remove the FindQt module
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: noo mook <noomook2519@gmail.com>
Merge-request: !2554
|
| |
| |
| |
| |
| |
| |
| |
| | |
Removing FindQt.cmake gives Qt upstream a path forward to export its
own QtConfig.cmake files which can be found by find_package()
without having to explicitly specify CONFIG. Projects that still
want to use Qt3/4 can call find_package(Qt[34]), include(FindQt),
or add FindQt.cmake to their CMAKE_MODULE_PATH.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Move deprecated or obsolete modules to the section
"Deprectated Modules" of cmake-modules(7):
- MacroAddFileDependencies (Text says: Using the macro
MACRO_ADD_FILE_DEPENDENCIES() is discouraged.)
- UsePkgConfig (Text calls it "obsolete")
- Use_wxWindows (was already listed in deprecation section)
|
|/ |
|
| |
|
|
|
|
| |
This module is inspired by one from KDE's KWin.
|
|
|
|
| |
This module is inspired by one from KDE's KWin.
|
|
|
|
| |
The implementation already logged a message saying that the module
was deprecated. This change adds that message to the module docs.
|
|
|
|
|
|
|
|
| |
* Split up module list into separate sections for utility modules
and find modules.
* Improve wording to explain how the different module types
are expected to be called/used.
* Move deprecated modules to their own separate sections.
|
|
|
|
|
|
|
| |
These modules are being moved out of user visibility and into an
internal section of CMake. To keep them for historical reference in
the manual, this commit moves them into a separate "Legacy CPack
Modules" section.
|
|
|
|
| |
Add tests for FindODBC module.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Create a CPack generator that uses `nuget.exe` to create packages:
https://docs.microsoft.com/en-us/nuget/what-is-nuget
NuGet packages could be easily produced from a `*.nuspec` file (running
`nuget pack` in the directory w/ the spec file). The spec filename does
not affect the result `*.nupkg` name -- only `id` and `version` elements
of the spec are used (by NuGet).
Some implementation details:
* Minimize C++ code -- use CMake script do to the job. It just let the
base class (`cmCPackGenerator`) to preinstall everything to a temp
directory, render the spec file and run `nuget pack` in it, harvesting
`*.nupkg` files...;
* Ignore package name (and use default paths) prepared by the base class
(only `CPACK_TEMPORARY_DIRECTORY` is important) -- final package
filename is a responsibility of NuGet, so after generation just scan the
temp directory for the result `*.nupkg` file(s) and update
`packageFileNames` data-member of the generator;
* The generator supports _all-in-one_ (default), _one-group-per-package_
and _one-component-per-package_ modes.
|
|
|
|
| |
Fixes: #16142
|
|
|
|
|
| |
This module provides abstraction over the various ways POSIX platforms
handle the iconv calls defined in POSIX.1-2001 and later versions.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds an option CPACK_ENABLE_FREEBSD_PKG to allow CPack to look
for FreeBSD's libpkg / pkg(8). If this is set and the libpkg
headers and library are found (which they will be, by default,
on any FreeBSD system), then add a FreeBSD pkg(8) generator.
The FreeBSD package tool pkg(8) uses tar.xz files (.txz) with two
metadata files embedded (+MANIFEST and +COMPACT_MANIFEST).
This introduces a bunch of FreeBSD-specific CPACK_FREEBSD_PACKAGE_*
variables for filling in the metadata; the Debian generator does
something similar. Documentation for the CPack CMake-script is styled
after the Debian generator.
Implementation notes:
- Checks for libpkg -- the underlying implementation for pkg(8) --
and includes FreeBSD package-generation if building CMake on
a UNIX host. Since libpkg can be used on BSDs, Linux and OSX,
this potentially adds one more packaging format. In practice,
this will only happen on FreeBSD and DragonflyBSD.
- Copy-paste from cmCPackArchiveGenerator to special-case
the metadata generation and to run around the internal
archive generation: use libpkg instead.
- Generating the metadata files is a little contrived.
- Most of the validation logic for package settings is in
CPackFreeBSD.cmake, as well as the code that tries to re-use
packaging settings that may already be set up for Debian.
- libpkg has its own notion of output filename, so we have
another contrived bit of code that munges the output file
list so that CPack can find the output.
- Stick with C++98.
|
|
|
|
|
|
| |
Support for setting archive packager specific
per component filenames and monolithic package
filenames.
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
506207f9 VS: add test for VS_CSHARP_* source file property
a202749c VS: add CSharpUtilities module
9588d0a2 VS: add VS_CSHARP_<tagname> sourcefile property
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
| |
Extract the `gtest_add_tests` macro from `FindGTest` into a separate
module. GTest or GoogleTest can be used by a project in a several
different ways, including installed libraries in the system, from an
ExternalProject, or adding the GTest source directory as a sub directory
of the project. As not all of these uses are supported by the FindGTest
module the useful `gtest_add_tests` macro is separated to easily enable
reuse.
Issue: #14151
|
| |
|
|
|
|
|
|
| |
Add a module to manage the data needed for the project tests. It will
move the test data to the build directory and transfer necessary data to
an Android device if that is enabled.
|