The function `cmFortranParser_FilePush` was always processing the
provided (included) file, even though it may have been processed before.
This lead to infinite recursion in cases where the include guards were
not properly interpreted, e.g. `# if !defined` instead of `#ifndef`.
This commit introduces a cache of paths to already processed files.
These files are now ignored in `cmFortranParser_FilePush` (treated as
non-existing).
Fixes: #27238
Since it can be set in the environment when running the test suite,
guard tests which are sensitive to intermediate directory strategy
changes with explicit settings.
- Added intro code blocks showing how to include these modules.
- Used word "command" instead of "macro".
- Added examples sections.
- Updated and synced descriptions of commands and arguments.
- Added a rubric title for variables that affect the checks.
- Listed CMAKE_TRY_COMPILE_TARGET_TYPE variable in the rubric together
with CMAKE_REQUIRED_* variables.
- Added link to CheckCompilerFlag module in the target_compile_options()
docs.
- Used lowercase style for check_fortran_compiler_flag() command.
- Added a link to `$<COMPILE_LANGUAGE:languages>` generator expression
so it can be linked from other pages (See commit
2e37a20f02 for more info on the initial
style used).
- Fixed the GENEX_NOTE inclusion (starting with line after the 2nd line)
where part of the sentence was rendered in the output.
Changes:
- Added intro code blocks showing how to include these modules.
- Added examples sections.
- Used "command" instead of "macro".
- Commands sections added to have a clearer overview of the modules at
first encounter.
- Reworded commands arguments a bit.
- Added a rubric title for variables that affect the checks.
- CheckFortranSourceCompiles: Added CMake version when SRC_EXT option
was introduced.
- Listed CMAKE_TRY_COMPILE_TARGET_TYPE variable in the rubric together
with CMAKE_REQUIRED_* variables and added an include RST file for it.
- Used lowercase style for check_fortran_source_compiles().
Replace our hard-coded default for `/RTC1` with a first-class
abstraction to select runtime checks from an enumeration of logical
names. Add a `MSVC_RUNTIME_CHECKS` target property and corresponding
`CMAKE_MSVC_RUNTIME_CHECKS` variable.
Removing the old default flag requires a policy because existing
projects may rely on string processing to edit them and choose
runtime checks under the old behavior. Add policy CMP0184 to
provide compatibility.
Fixes: #26614
This was added in commit 98d0f918ba (LFortran: Add support for this
compiler, 2024-01-25, v3.31.0-rc1~303^2~2) because it is needed for
cases covered by CMake's Fortran tests. However, it does not work
with Fortran modules and breaks lfortran's own `examples/project1`.
Move the flag to the test cases that need it, just as the original
commit did with `--implicit-interface`.
Fixes: #26597
Co-authored-by: Brad King <brad.king@kitware.com>
Fix a typo from commit e522f8ca06 (cmTarget: factor out properties
initialized for target which compile, 2023-02-01, v3.27.0-rc1~577^2~13),
that broke this property.
Also update the test suite to use this upgrade as some level of
coverage.
Fixes: #25123
CMake 3.27 deprecates compatibility with CMake < 3.5. Update tests that
do not cover older interfaces to avoid the deprecation warning.
Follow the pattern from:
* commit 7b07ccdd2b (Tests/*Only: Update cmake_minimum_required versions,
2020-06-15, v3.19.0-rc1~629^2~1)
* commit 72e7c45e98 (Tests: Bump CMake minimum required in tests to 2.8.12,
2020-12-22, v3.20.0-rc1~224^2)
* commit f6b4db365a (Tests: bump cmake_minimum_required version to 2.8.12,
2021-04-04, v3.21.0-rc1~372^2)
Also remove explicit `cmake_policy` settings made redundant by the
version.
LCC < 1.24 has no way to disable integrated Fortran preprocessor,
and it can't produce preprocessed files explicitly. So we
disable all functionality (and therefore tests) related to it.
If `Fortran_PREPROCESS` is explicitly turned off for a source file then
we know it does not need to be preprocessed. Teach the Ninja generator
to skip preprocessing in this case. Otherwise we still must preprocess
just in case.
Fixes: #18870
The test project is compiled with a `-DVAR` compiler flag where `VAR` is
the result variable. Tell `try_compile` to add the flag through
`add_definitions` instead of `CMAKE_Fortran_FLAGS` so that it is not
used for linking. Otherwise some Fortran compilers (e.g. XL 15) do not
like the flag when used to drive linking.
The Intel Fortran compiler supports an extension that allows conditional
compilation based on preprocessor definitions specified on the command
line even when not preprocessing.
Fixes: #19664
The Intel Fortran `.vfproj` files do support both Fortran and the
Windows Resource compiler (`.rc)` files. Prior to CMake 3.9 we did not
support that, but commit 2c9f35789d (VS: Decide project type by linker
lang as fallback, 2017-03-30, v3.9.0-rc1~340^2) accidentally enabled it.
It was then broken by commit d3d2c3cd49 (VS: Fix Fortran target type
selection when linking C++ targets, 2019-02-04, v3.14.0-rc1~13^2).
Restore support for Fortran+RC in VS projects and add a test case.
Fixes: #19002
This version of the Intel Fortran plugin to Visual Studio says:
please make sure that $(OutDir), $(TargetName) and $(TargetExt)
property values match the value specified in %(Link.OutputFile)
We must set TargetName and TargetExt in addition to the existing
setting for OutputDirectory. The settings do not appear to hurt
older versions of Intel Fortran, so set them unconditionally.
Extend the FortranOnly test to cover a corresponding use case by
using the OUTPUT_NAME target property.
Inspired-by: Ian Harvey <Ian.Harvey@megms.com.au>
Copy the CheckCSourceCompiles module and port it to Fortran.
Extend the FortranOnly test to try using the new module.
Suggested-by: Nicolas Bock <nicolasbock@gmail.com>
Define a "Fortran_FORMAT" target and source file property. Initialize
the target property from a "CMAKE_Fortran_FORMAT" variable. Interpret
values "FIXED" and "FREE" to indicate the source file format. Append
corresponding flags to the compiler command line.
For custom commands in VS2010 Fortran projects the INTDIR variable
is different than in the rest of the solution because Intel
fortran still uses the old VS project files even in VS2010. So,
we replace $(Configuration) directly in the project files. I have also
added a FortranOnly test that tests this feature and is run on any
generator that has Fortran abilities.
