fe8f08d2 find_*: Add docs for PackageRoot search path group
57744ca9 find_*: Add tests for PackageRoot search path group
ef3d360a find_*: Add a new PackageRoot search path group
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !796
Allow CTest script writers to specify additional HTTP headers to be sent
to CDash during submission.
The motivating case for this feature is a corresponding change in CDash.
This will allow projects to refuse submissions from any site not bearing
a valid authentication token.
eec93bce Allow OBJECT libraries to be installed, exported, and imported
93c89bc7 Genex: Allow TARGET_OBJECTS to be used everywhere
ac0cf7ff Genex: Reject TARGET_OBJECTS on non-object libraries earlier
8577978c Tests: ExportImport C code should use explicit (void) in prototypes
26cfd039 cmInstallTargetGenerator: Re-order GenerateScriptForConfig logic
25f3f22a cmGlobalGenerator: Add method to check if object file location is known
d596c550 cmGeneratorTarget: Add method to get the object file directory
930042f2 cmGeneratorTarget: Factor out a GetTargetObjectNames method
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !712
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>
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`.
Detect x32-abi through CMakeCompilerABI infrastruture and use this
information at runtime to determine the correct library paths with
`FIND_LIBRARY_USE_LIBX32_PATHS`.
Fixes: #15994
Add a new `CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX` variable to allow use
of a custom suffix on `lib` directory names. This is a more general
option than that added by commit v3.7.0-rc1~504^2 (Teach find_library
and find_package to search lib32 paths, 2016-06-10). It allows the find
path to be more deterministic on custom setups.
See discussion in #10287 and #15994.
Since commit v3.8.0-rc1~232^2 (execute_process: Add ENCODING option for
Windows child process output, 2016-11-23) we decode child process output
using the console's active codepage by default. This differs from
previous versions of CMake and is therefore incompatible. Changing this
default will require a policy, so for now revert the default behavior
back to performing no decoding.
Reported-by: Nils Gladitz <nilsgladitz@gmail.com>
Some of our "cmake" code blocks do not use fully valid CMake syntax
because they have placeholders for human reference. Sphinx has
never been able to properly lex and highlight these, but now warns.
Fix each block's syntax or change to a non-cmake block as appropriate.
071f8e78 Apple: Add support for static frameworks
d525754e Xcode: Refactor RunCMake.Framework test to prepare for static frameworks
45405f00 Xcode: Ignore Xcode project warning until issue is fixed
50e1c105 Makefile: For static libraries remove only the "real" lib before creating
8643ca75 Makefile: Re-order list of files to clean
Projects use `try_compile` to check if they will be able to compile some
particular source code. When a language standard variable like
`CMAKE_CXX_STANDARD` is set, then the project intends to compile source
code using a compiler mode for that standard. Therefore it makes sense
for `try_compile` to use that standard in the test project too.
Unfortunately this was not done when support for the
`CMAKE_CXX_STANDARD` variable was first implemented. Add a policy to
introduce the improved behavior in a compatible way.
Closes: #16456
Give `try_compile` callers a way to control the `CXX_STANDARD`,
`CXX_STANDARD_REQUIRED`, and `CXX_EXTENSIONS` properties of the
generated test target (or the `C` equivalents) in order to compile a
test source for a particular language standard.
Issue: #16456
f636d1e7 Help: Add notes for topic 'add-SHA-3'
cb5dba8e Tests: Add SHA-3 algorithm coverage to CPack checksum test
a9fa6099 ExternalProject: Add support for SHA-3 algorithms
b4ffd26f ExternalData: Add support for SHA-3 algorithms
60939702 file: Add support for SHA-3 algorithms
92f95aed string: Add support for SHA-3 algorithms
c326209f cmCryptoHash: Add support for SHA-3 algorithms
979e8ba6 Help: De-duplicate and spell out supported hash algorithms
7a79f7e3 librhash: Activate SHA-3 implementation
87584b5e Merge branch 'upstream-librhash' into add-SHA-3
7fcbd47e librhash 2016-11-06 (de79828d)
c50c32a3 librhash: Update import script to add SHA-3 implementation
Spell out the supported algorithms in a definition list in the
`string(<HASH>)` command documentation. Revise the `file(<HASH>)`
command and CPack module documentation to reference it instead of
duplicating the list.
The execute_process command starts all commands in parallel (in order
for the piping to work). Mention this explicitly and also add a note
about how to execute commands sequentially.
