- Added intro code blocks showing how to use find modules.
- Synced modules documentation.
- Extended few examples to make the intro code blocks fit into the
modules descriptions.
- Synced some RST formatting, variables descriptions and positions.
- Removed few redundant internal comments.
Issue: #26555
This fixes Sphinx warning `Unexpected section title or transition`.
RST transition element (horizontal line) cannot appear inside some
container-like elements.
- Updated and synced module documentation with other similar find
modules.
- Documented bison_target() command indented relative to the title.
- Command arguments described as a list separately.
- Used "command" instead of "macro".
- Used lowercase style across the docs.
- Extended examples section.
Since commit d74210a8bd (CMP0017: Remove support for OLD behavior,
2024-11-17) we can rely on CMP0017's NEW behavior unconditionally.
Calling `include(FindPackageHandleStandardArgs)` in a builtin module
will always get the builtin `FindPackageHandleStandardArgs`.
This adds a new keyword OPTIONS which is a semicolon-separated list of
command-line options added to bison command line. This enables adding
options more intuitively. It mainly adds options as quoted arguments
which among other things enables adding paths containing spaces and
similar.
Fixes:
- https://gitlab.kitware.com/cmake/cmake/-/issues/23301
Bison and Flex executables at the time of writing don't create
output directories when generating files. In most cases this isn't issue
if the build directory is created before running bison or flex. If any
of the output directories that can be determined isn't available, these
modules now create them before running the bison or flex command.
Issue: #19529
When using generator expressions in the COMPILE_FLAGS argument, and the
generator expression expands to an empty string, command gets an empty
argument with double quotes where GNU bison command-line tool errors out
with `/usr/bin/bison: extra operand` error. This removes empty arguments
from the created bison command.
Now that the working directory is in the build tree, relative input
paths must be converted to an absolute path to remain relative to the
source directory.
Fixes: #19472
When `BISON_TARGET` is called with both
VERBOSE <extra-file> REPORT_FILE <file>
we add a custom command to copy `<file>` to `<extra-file>`. The change
in commit v3.7.1~10^2 (FindBISON: Do not rebuild every time when not
VERBOSE, 2016-11-14) incorrectly listed the extra file as an output of
the main bison invocation custom command, but it is actually produced by
the separate copy command. Fix the logic to always generate `<file>` as
an output of the bison command and `<extra-file>` as an output of the
copy command.
Fixes: #18433
The cmake_parse_arguments command is builtin with version 3.5.
The CMakeParseArguments module is empty and exists for backwards
compatibility with CMake 3.4 and lower.
Remove the includes of CMakeParseArguments from CMake's modules.
The modules are always used with the current version of CMake.
Leave the includes in the tests, as the tests may be run with an older
version of CMake.
Since commit v3.7.0-rc1~348^2~3 (FindBISON: Change usage of [VERBOSE
<file>] to [VERBOSE [<file>]], 2016-07-16) we always list the VERBOSE
output file as an output of our custom command even if the option is not
used. This causes the rule to re-run every time (e.g. with Ninja).
Revert one hunk from that change (that looks incorrect) to fix it.
Closes: #16426
Per-source copyright/license notice headers that spell out copyright holder
names and years are hard to maintain and often out-of-date or plain wrong.
Precise contributor information is already maintained automatically by the
version control tool. Ultimately it is the receiver of a file who is
responsible for determining its licensing status, and per-source notices are
merely a convenience. Therefore it is simpler and more accurate for
each source to have a generic notice of the license name and references to
more detailed information on copyright holders and full license terms.
Our `Copyright.txt` file now contains a list of Contributors whose names
appeared source-level copyright notices. It also references version control
history for more precise information. Therefore we no longer need to spell
out the list of Contributors in each source file notice.
Replace CMake per-source copyright/license notice headers with a short
description of the license and links to `Copyright.txt` and online information
available from "https://cmake.org/licensing". The online URL also handles
cases of modules being copied out of our source into other projects, so we
can drop our notices about replacing links with full license text.
Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority
of the replacements mechanically. Manually fix up shebang lines and trailing
newlines in a few files. Manually update the notices in a few files that the
script does not handle.
The matches have already been calculated and can simply be taken from
CMAKE_MATCH_n variables. This avoids multiple compilations of the same or very
similar regular expressions.
Ancient versions of CMake required else(), endif(), and similar block
termination commands to have arguments matching the command starting the
block. This is no longer the preferred style.
Run the following shell code:
for c in else endif endforeach endfunction endmacro endwhile; do
echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/'
done >convert.sed &&
git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' |
egrep -z -v '^(Utilities/cm|Source/kwsys/)' |
egrep -z -v 'Tests/CMakeTests/While-Endwhile-' |
xargs -0 sed -i -f convert.sed &&
rm convert.sed
I've just found out that use of FindBISON.cmake shipped with CMake 2.8
on system where bison++ is default bison executable (e.g. Debian Linux)
will result in corrupted CMakeCache.txt file and parse error due to
"Offending entry"
As FindBISON.cmake logic used to obtain installed bison executable
version is tailored to match only the message used in GNU Bison it fails
on absolutely different Bison++ version message and whole version
message including \n characters is stored into BISON_VERSION which is
then dumped into CMakeCache.txt, so everything after first \n character
makes "Offending entry".
The FindPackageHandleStandardArgs module was originally created outside
of CMake. It was added for CMake 2.6.0 by commit e118a627 (add a macro
FIND_PACKAGE_HANDLE_STANDARD_ARGS..., 2007-07-18). However, it also
proliferated into a number of other projects that at the time required
only CMake 2.4 and thus could not depend on CMake to provide the module.
CMake's own find modules started using the module in commit b5f656e0
(use the new FIND_PACKAGE_HANDLE_STANDARD_ARGS in some of the FindXXX
modules..., 2007-07-18).
Then commit d358cf5c (add 2nd, more powerful mode to
find_package_handle_standard_args, 2010-07-29) added a new feature to
the interface of the module that was fully optional and backward
compatible with all existing users of the module. Later commit 5f183caa
(FindZLIB: use the FPHSA version mode, 2010-08-04) and others shortly
thereafter started using the new interface in CMake's own find modules.
This change was also backward compatible because it was only an
implementation detail within each module.
Unforutnately these changes introduced a problem for projects that still
have an old copy of FindPackageHandleStandardArgs in CMAKE_MODULE_PATH.
When any such project uses one of CMake's builtin find modules the line
include(FindPackageHandleStandardArgs)
loads the copy from the project which does not have the new interface!
Then the including find module tries to use the new interface with the
old module and fails.
Whether this breakage can be considered a backward incompatible change
in CMake is debatable. The situation is analagous to copying a standard
library header from one version of a compiler into a project and then
observing problems when the next version of the compiler reports errors
in its other headers that depend on its new version of the original
header. Nevertheless it is a change to CMake that causes problems for
projects that worked with previous versions.
This problem was discovered during the 2.8.3 release candidate cycle.
It is an instance of a more general problem with projects that provide
their own versions of CMake modules when other CMake modules depend on
them. At the time we resolved this instance of the problem with commit
b0118402 (Use absolute path to FindPackageHandleStandardArgs.cmake
everywhere, 2010-09-28) for the 2.8.3 release.
In order to address the more general problem we introduced policy
CMP0017 in commit db44848f (Prefer files from CMAKE_ROOT when including
from CMAKE_ROOT, 2010-11-17). That change was followed by commit
ce28737c (Remove usage of CMAKE_CURRENT_LIST_DIR now that we have
CMP0017, 2010-12-20) which reverted the original workaround in favor of
using the policy. However, existing project releases do not set the
policy behavior to NEW and therefore still exhibit the problem.
We introduced in commit a364daf1 (Allow users to specify defaults for
unset policies, 2011-01-03) an option for users to build existing
projects by adding -DCMAKE_POLICY_DEFAULT_CMP0017=NEW to the command
line. Unfortunately this solution still does not allow such projects to
build out of the box, and there is no good way to suggest the use of the
new option.
The only remaining solution to keep existing projects that exhibit this
problem building is to restore the change originally made in commit
b0118402 (Use absolute path to FindPackageHandleStandardArgs.cmake
everywhere, 2010-09-28). This also avoids policy CMP0017 warnings for
this particular instance of the problem the policy addresses.
This puts the new search behaviour for included files in action, i.e.
now when a file from Modules/ include()s another file, it also gets the
one from Modules/ included, i.e. the one it expects.
Alex
This additional mode also supports version checking and should be
easily extendible, e.g. for COMPONENT stuff.
Updated FindBISON.cmake as first user of this new mode.
Docs updated.
Alex
Most problems are fixed (or rather worked-around) by making long '====='
separators pre-formatted (i.e. prefixed with two spaces). In order to
preserve visual view, the code examples themselves are prefixed with 3
spaces.
This commit fixes the following man warnings:
$ cmake --help-man - | LANG=C MANWIDTH=80 man --warnings -l - > /dev/null
<standard input>:6024: warning [p 105, 1.7i]: can't break line
<standard input>:6027: warning [p 105, 2.7i]: cannot adjust line
<standard input>:6027: warning [p 105, 2.8i]: can't break line
<standard input>:7142: warning [p 117, 7.8i]: can't break line
<standard input>:7171: warning [p 117, 11.8i]: can't break line
<standard input>:8878: warning [p 136, 9.0i]: can't break line
<standard input>:8887: warning [p 136, 11.5i]: cannot adjust line
<standard input>:8887: warning [p 136, 11.7i]: can't break line
<standard input>:8904: warning [p 136, 14.2i]: can't break line
Patch from Modestas Vainius. See issue #9659.
