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.
