In commit 695f0d0d3a (cmFortranParser: Parse keywords as lexical tokens,
2016-09-05, v3.7.0-rc1~150^2) we created keyword-specific variants of
the original `USE WORD other EOSTMT` production, such as
`MODULE WORD other EOSTMT` and `INTERFACE WORD other EOSTMT`. The same
pattern was used by more keyword-specific productions in commit b5ac8b8aa7
(Fortran: Add support for submodule syntax in dependency scanning,
2016-09-05, v3.7.0-rc1~73^2~1).
The postfix part (`other`) of several keyword-specific productions is
not needed to match Fortran syntax. See the Fortran 2018 standard,
para.4.1.4/1 on p.28, para.14.2.1/2 on pp.293-294. The postfix is
needed only for a case of operator 'use':
use <module-name> [, only : <list-of-vars>]
The unnecessary postfix matching from the keyword-specific productions
such as module, submodule, and interface declarations can cause spurious
module dependencies to be detected, so remove it.
Extend the test suite with examples covering the previously-broken
cases.
Fixes: #18427
We read sources in binary format, so we need to explicitly match CR
(`\r`) characters that occur as part of newlines in CRLF sources.
This is particularly important when line continuation (`&`) occurs
in the middle of module declaration or usage.
a6abdf6c8f Help: Consistent options declaration -- short first, then long
f4563f05db Help: Value for `--graphviz=` option actually is mandatory
04843d743e Help: Replace a bunch of more ``--option`` to `:option:` role
09446266ee Help: Replace mentions of ``-D`` option with :option:`-D` role
b57f27b087 Help: Replace mentions of ``-T`` and ``-A`` options with role
d25b232dee Help: Replace mentions of ``-G`` option with :option:`-G` role
63940e1cab Help: Replace mentions of ``-C`` option with :option:`-C` role
183a49cbfe Help: Replace mentions of ``-S`` option with :option:`-S` role
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7544
The `PREFIX/(Foo|foo|FOO).*/(cmake|CMake)/(Foo|foo|FOO).*/` search
path is the similar to the one already exists
`PREFIX/(Foo|foo|FOO).*/(lib/ARCH|lib*|share)/cmake/(Foo|foo|FOO).*/`.
Directory-level rules in `CMakeFiles/Makefile2` were previously
previously written by each directory's local generator using its own
decision for using relative or absolute paths.
Since commit d33b12d84b (Add support for build tree symlink inside
source tree, 2022-02-25, v3.24.0-rc1~583^2), each local generator
explicitly models the relationship between its source and build paths,
and uses this to determine when it is safe to use relative paths.
Because `add_subdirectory` supports arbitrary placement of the source
and build directories, different local generators may have different
relationships between their source and build paths. This can cause
disagreement among rules written to `CMakeFiles/Makefile2`.
Restore consistency by always using the root local generator to write
rules to `CMakeFiles/Makefile2`. Relative paths should always be
expressed w.r.t. the top-level build directory since that is the working
directory in which the `make` tool processing the file will run.
Fixes: #23814
4f95e6b284 ci: test BMI exporting and installation with GCC in CI
c49d5f137b RunCMake/CXXModules: add a "deep-chain" test
297e0f4dce cmCxxModuleMapper: support MSVC module map format
b3c2880cb2 cmCxxModuleMapper: track transitive modules for MSVC
a43713d615 CTestCustom: ignore `cm::optional` uninitialized memory false positive
b90de0b492 RunCMake/CXXModules: support MSVC extensions
a84c186a7d cmScanDepFormat: support the MSVC 17.3 toolchain temporarily
d7f5064ff7 cmScanDepFormat: support P1689R5
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7481
The point is that `cmFileListBlahBlahGenerator` actually "generate"
directory names and never files.
The `cmBlahBlahStringGenerators` produce paths in fact. Ok, paths
nowadays are also strings but...
The `cmFileListGeneratorProject` and `cmFileListGeneratorMacProject`
was look very similar 'cept few lines.
Now they have a base class and the generator-specific logic has moved
to overrides.
Original code had path generators built at run-time using a linked list
of dynamically allocated nodes each of which was responsible to generate
a path segment.
However, the combination of used generators is totally well known at
compile time.
