22da18b995 Fortran: Restore support for TARGET_OBJECTS providing modules
64d9240564 cmComputeLinkInformation: skip over linking to items for object purposes
035302b7e3 cmComputeLinkDepends: also copy the target from object link items
861876b936 Tests/ObjectLibrary: fix comment
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Acked-by: scivision <michael@scivision.dev>
Merge-request: !8923
Continue b665966933 (cmComputeLinkInformation: track OBJECT library
dependencies, 2023-07-22) which added explicitly listed `OBJECT`
libraries to the list of targets which the collator needs to consider.
Now also consider targets which provide objects directly to the target
via a `$<TARGET_OBJECT>` source lists.
Also add tests which use target objects directly and through an
`INTERFACE` library with target objects in its own sources.
Fixes: #25365
Since commit 74b1d6caf3 (cmComputeLinkInformation: compute link info for
module-using targets, 2023-09-05, v3.27.5~7^2) we accidentally try to
compute link information for custom targets if they have Fortran
sources. For module dependencies, we only need to consider target types
that can compile.
Fixes: #25252
Since
* commit eed295fd8a (cmGlobalNinjaGenerator: require that dependency info
files work, 2023-02-01, v3.26.0-rc1~1^2~1), and
* commit 13810dee17 (cmDependsFortran: require that dependency info files
work, 2023-02-01, v3.26.0-rc1~1^2),
the Ninja and Makefile generators' module dependency scanning requires
that scanning results from from linked targets is available before
scanning the current target. In the case of a static library cycle,
we cannot expect this information from other static libraries in the
cycle. Previously we supported cyclic cases at the cost of silently
ignoring missing information.
We already compute a global order of targets that respects all
`add_dependencies`, but may break `target_link_libraries` dependencies
that occur in a static library cycle. Use this order to filter the
linked targets so we only expect scanning results to be available from
those targets that build before the current target.
This approach is sufficient to support module dependency scanning in
static library cycles as long as module dependencies do not cross
between two libraries in the same cycle.
Fixes: #24631
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
Since commit b66bc6606e (Tests: Add Fortran submodule tests, 2016-09-22,
v3.7.0-rc1~55^2) we try a small test program to see if the Fortran
compiler supports submodules. However, a typo in the test program
caused it to fail on XL with the error:
1513-083 (E) Internal or module function id was not set within the function.
Fix the typo so that the check passes and enables the submodule tests
with XL compilers.
When GNU `ar` creates an archive with no symbols it has only an
empty header but no string table. On Solaris the OS-provided `ld`
fails in this case:
ld: elf error: file libfoo.a: elf_getarsym
Update our test to actually provide symbols from its archives.
The lexical token expression added by commit v3.7.0-rc1~73^2~1 (Fortran:
Add support for submodule syntax in dependency scanning, 2016-09-05)
has a typo and does not match upper-case `B` in `SUBMODULE`. Fix it.
Fixes: #18595
Since commit v3.7.0-rc1~73^2~1 (Fortran: Add support for submodule
syntax in dependency scanning, 2016-09-05) we support parsing Fortran
sources that use submodule syntax, but it left addition of `.smod`
dependencies to future work. Add it now.
The syntax
submodule (module_name) submodule_name
means the current source requires `module_name.mod` and provides
`module_name@submodule_name.smod`. The syntax
submodule (module_name:submodule_name) nested_submodule_name
means the current source requires `module_name@submodule_name.smod`
provides `module_name@nested_submodule_name.smod`.
Fixes: #17017
Some are user facing.
Found using
codespell -q 3 --skip="./Utilities" -I .cmake-whitelist.txt`
whereby the whitelist contained:
ans
dum
helpfull
emmited
emmitted
buil
iff
isnt
nto
ot
pathes
substract
te
todays
upto
whitespaces
Fortran INCLUDE statements are not handled by the preprocessor.
Since the location of the preprocessed file is distinct from the
original source file explicitly add the source file's directory
as an include path in the actual compile step (not the preprocessing step)
so INCLUDE can find it.
Closes: #16332
