summaryrefslogtreecommitdiffstats
path: root/Tests/FortranModules
Commit message (Collapse)AuthorAgeFilesLines
* Tests/FortranModules: add test for TARGET_OBJECTS-as-linked-items module usageBen Boeckel2023-11-2110-0/+69
| | | | | | Test module usage across a `$<TARGET_OBJECTS>`-as-linked-items use case. See: #25425
* Tests/FortranModules: add test for TARGET_OBJECTS-as-sources module usageBen Boeckel2023-11-218-0/+63
| | | | | | Test module usage across a `$<TARGET_OBJECTS>`-as-sources use case. See: #25425
* Fortran: Restore support for TARGET_OBJECTS providing modulesBen Boeckel2023-10-307-0/+67
| | | | | | | | | | | | | 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
* Tests/FortranModules: add a test for iface Fortran sourcesBen Boeckel2023-09-205-0/+38
| | | | | This tests that a library that doesn't compile Fortran sources but provides one via `INTERFACE` sources works as intended.
* Tests/FortranModules: also test INTERFACE targets with Fortran sourcesBen Boeckel2023-09-204-0/+22
|
* add_custom_target: Fix regression with Fortran sourcesBen Boeckel2023-09-204-0/+26
| | | | | | | | | | 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
* Tests/FortranModules: add a test case for #25223Ben Boeckel2023-09-187-0/+81
|
* Tests/FortranModules: move issue 25112 fix from FortranOnlyBen Boeckel2023-09-184-0/+18
| | | | It involves modules, so it belongs in the `FortranModules` test set.
* Ninja,Makefile: Restore Fortran module scanning in static library cycleBrad King2023-03-247-1/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Tests/FortranModules: add case for modules after "end interface X"Ben Boeckel2022-11-303-0/+22
| | | | | | | When there is an `end interface X` in a file, subsequent modules should not be considered part of interface X. Issue: #24203
* Fortran: Fix suprious dependencies with submodulesVitaly Mogulian2022-08-094-3/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Tests: Fix FortranModules test with Intel compiler on WindowsBrad King2021-03-091-0/+5
| | | | | The test regularly fails updating the `vc*.pdb` compiler-generated PDB file. Add the `/Z7` flag as the compiler suggests for this.
* Tests: Enable Fortran submodule tests on XL compilersBrad King2020-02-281-1/+1
| | | | | | | | | | | | 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.
* Ninja: Add multi-config variantKyle Edwards2019-12-131-1/+1
| | | | Co-Authored-by: vector-of-bool <vectorofbool@gmail.com>
* Tests: Add symbols to FortranModules static librariesBrad King2019-09-263-0/+9
| | | | | | | | | | 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.
* Fortran: Fix module dependency scanning with upper-case SUBMODULEBrad King2018-11-201-3/+3
| | | | | | | | 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
* Fortran: Extend submodule test with great-grandchildBrad King2018-04-205-0/+23
| | | | | Name the module using CamelCase to test lower-case file name conversion. Also add coverage of existing "sibling" module.
* Fortran: Add support for submodule dependenciesBrad King2018-04-206-58/+59
| | | | | | | | | | | | | | | | | | | | | 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
* GENERATOR_IS_MULTI_CONFIG: Use for multi-config checks in TestsCraig Scott2017-12-291-2/+3
|
* Fix trivial typos in textluzpaz2017-11-032-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Ninja: Add source location as include directory for preprocessed filesNils Gladitz2016-09-273-0/+10
| | | | | | | | | | | 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
* Tests: Add Fortran submodule testsBrad King2016-09-234-0/+94
| | | | | Co-Author: Damian Rouson <damian@sourceryinstitute.org> Issue: #16234
* Tests: Split Fortran module testing into separate FortranModules testBrad King2016-09-2221-0/+237
The main Fortran test is not granular enough. Split some into another test.
generated by cgit v0.12 at 2025-01-11 05:04:29 (GMT)