@certik, could you confirm whether lfortran on Windows currently has known issues, or if something else might be going wrong?
Run fpm test --compiler lfortran --profile debug --verbose
+ mkdir build\dependencies
<INFO> BUILD_NAME: build\lfortran
<INFO> COMPILER: lfortran
<INFO> C COMPILER: cc
<INFO> CXX COMPILER: cc
<INFO> COMPILER OPTIONS: -fPIC
<INFO> C COMPILER OPTIONS:
<INFO> CXX COMPILER OPTIONS:
<INFO> LINKER OPTIONS:
<INFO> INCLUDE DIRECTORIES: []
+ mkdir build\lfortran_1C9F1A78448FC13A
+ mkdir build\lfortran_68BEE2AA1F5C26E0
[ 0%] main.f90
+ mkdir build\lfortran_1C9F1A78448FC13A\test\
+ lfortran -c .\.\src\main.f90 -fPIC -J build\lfortran_1C9F1A78448FC13A -Ibuild\lfortran_1C9F1A78448FC13A -o build\lfortran_1C9F1A78448FC13A\test\src_main.f90.o
[ 25%] main.f90 done.
<ERROR> Compilation failed for object " src_main.f90.o "
<ERROR> stopping due to failed compilation
STOP 1
Error: Process completed with exit code 1.
Also, flang + fpm on Windows gives:
Run fpm test --compiler flang-new --profile debug --verbose
+ mkdir build\dependencies
<INFO> BUILD_NAME: build\flang-new
<INFO> COMPILER: flang-new
<INFO> C COMPILER: clang
<INFO> CXX COMPILER: clang++
<INFO> COMPILER OPTIONS: -fPIC
<INFO> C COMPILER OPTIONS:
<INFO> CXX COMPILER OPTIONS:
<INFO> LINKER OPTIONS:
<INFO> INCLUDE DIRECTORIES: []
+ mkdir build\flang-new_1C9F1A78448FC13A
+ mkdir build\flang-new_68BEE2AA1F5C26E0
[ 0%] main.f90
+ mkdir build\flang-new_1C9F1A78448FC13A\test\
+ flang-new -c .\.\src\main.f90 -fPIC -module-dir build\flang-new_1C9F1A78448FC13A -Ibuild\flang-new_1C9F1A78448FC13A -o build\flang-new_1C9F1A78448FC13A\test\src_main.f90.o
flang-new: error: unsupported option '-fPIC' for target 'x86_64-pc-windows-msvc'
flang-new: error: unsupported option '-fPIC' for target 'x86_64-pc-windows-msvc'
[ 25%] main.f90 done.
flang-new: error: unsupported option '-fPIC' for target 'x86_64-pc-windows-msvc'
<ERROR> Compilation failed for object " src_main.f90.o "
<ERROR> stopping due to failed compilation
flang-new: error: unsupported option '-fPIC' for target 'x86_64-pc-windows-msvc'
STOP 1
Error: Process completed with exit code 1.
It looks like -fPIC isn’t supported on Windows for flang. Would it make sense to remove -fPIC from the default compiler options for flang on Windows in fpm?
Basic things should work on Windows, but we require the MSVC linker for linking. Where is the test file that you use? I can try it out and see what is going on.
For the third time (at least) almost all my CD/CI tests are broken so this looks like worth trying. My initial goal with github CD/CI was to standardize all my repositories to use the same test file, where the test installs fpm and ford and doxygen and a compiler on different platforms and then builds documents into the gh_page branch and runs fpm test for --profile debug and release; so yours looks very appealing as it does that for more compilers than I was doing anyway, at least for fpm test.
I found I needed to be able to supply fpm options on a per-OS / per-compiler basis in a few cases which I did with response files, but you might want to show how to select fpm options just for a specific compiler; and how to run ford and place the results into gh-pages as well.
Looks promising. Hope to try it soon; using conda might be much more stable and avoid the repeated breakage I have seen in methods. I was about ready to give up on github CD/CI as it seemed a constant maintenance problem. This looks like it might solve that.
The test is simple and can be found under src and test, with the corresponding fpm.toml file provided. Here is an example of the test result: GitHub Actions.
Thanks, @urbanjost! I hope that by adding more scenarios and tests, setup-fortran-conda can cover more situations and better support a variety of requirements.
I’ve added support for ford and doxygen in the dev branch. After some testing, I plan to merge it into the main branch.
I see two possible approaches without using response files:
Create separate jobs for each OS/compiler combination in the workflow file (which might lead to a lot of duplication).
Use a single workflow with a matrix strategy, as shown here: https://github.com/gha3mi/setup-fortran-conda/blob/dev/.github/workflows/CI.yml. In the matrix, you can define any variables you need. I’ve added flags for both debug and release profiles for example, and I’m using the include feature to handle specific OS/compiler combinations. This matrix-based setup hasn’t been merged into the main branch yet.
Alternatively, you can still use response files with setup-fortran-conda. The following pattern should work: fpm @<os>-<compiler>-<additional variables>. With supported matrix values:
program check
#if defined(TEST)
print *, "This is a test"
#endif
end program
with fpm test --compiler flang-new --flag "-DTEST", gives:
./test/check.f90:2:12: error: excess characters after expression
#if defined(TEST)
^^^^^^
<ERROR> Compilation failed for object " test_check.f90.o "
<ERROR> stopping due to failed compilation
STOP 1
It seems that when using flang-new, fpm requires the -cpp flag to be passed manually fpm test --compiler flang-new --flag "-cpp -DTEST". This isn’t the case for other compilers.
Most compilers adopt the convention that if the file extension is .f90, then no preprocessing occurs, and if the file extension is .F90, then preprocessing does occur.
Great - would you please open an Issue on the fpm repository? Let’s check the flang documentation, CLI commands are mostly similar to those of GCC so maybe we should only add -cpp as default cpp pre-processing flag for flang as well.
Installing base environment...
Preparing transaction: ...working... done
Executing transaction: ...working...
done
Warning: entry_point.py:256: DeprecationWarning: Python 3.14 will, by default, filter extracted tar archives and reject files or modify their metadata. Use the filter argument to control this behavior.
entry_point.py:256: DeprecationWarning: Python 3.14 will, by default, filter extracted tar archives and reject files or modify their metadata. Use the filter argument to control this behavior.
installation finished.
I got all the flang-new/gfortran/ifx cases working accept that the ifx one on windows
tells me it cannot find ISO_FORTRAN_ENV. Anyone know how to resolve that?
+ mkdir build\ifx_EE9A1522C6DEBE16\M_time\
+ ifx -c .\.\src\M_time__duplicate.f90 /Qdiag-error:10006 /check:all /error-limit:1 /Od /Z7 /assume:byterecl /free /module:build\ifx_EE9A1522C6DEBE16 -Ibuild\ifx_EE9A1522C6DEBE16 -o build\ifx_EE9A1522C6DEBE16\M_time\src_M_time__duplicate.f90.o
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2025.1.0 Build 20250317
Copyright (C) 1985-2025 Intel Corporation. All rights reserved.
.\.\src\M_time__duplicate.f90(2): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [ISO_FORTRAN_ENV]
use, intrinsic :: iso_fortran_env, only : stderr=>ERROR_UNIT
------------------^
.\.\src\M_time__duplicate.f90(1982): catastrophic error: Too many errors, exiting
compilation aborted for .\.\src\M_time__duplicate.f90 (code 1)
[ 0%] M_time__duplicate.f90 done.
I needed to skip the -fPIC switch on mswindows when using Fortran, as the executables would
not run; set up the preprocessor and directives to conditionally skip anywhere using kind=real128
for flang-new, add the --cpp switch for lfortran and so on to the point where for me personally,
a seperate script for each compiler+OS would be simpler, but your core setups let me test eight
os/compiler combinations automatically. That adds two compilers to what I had running (flang-new
and lfortran) and all mine had broken infrastructure accept the gfortran tests so this is very
useful to me.
I also like to have the status flags in the markdown either in README.md or a file just for that
purpose in STATUS.md instead of using the github actions menu to quickly see pass/fail and I did
not figure out how to do that with a file checking multiple compilers where I could see each
compiler/OS combination so going to individual files lets me do that (does anyone know how to break
a composit test into multiple flags?).
I forked your repository to use as a test case for CI. I believe I’ve resolved the issue related to: Error in opening the compiled module file. Check INCLUDE paths. [ISO_FORTRAN_ENV]
However, there’s now a different error:
test\test_suite_M_time.F90(187): error #6626: The name of the internal procedure conflicts with a name in the encompassing scoping unit. [PUT_ENVIRONMENT_VARIABLE]
subroutine put_environment_variable(name,value,status)
Your fix worked; but I needed to add /fpp for ifx running in pure windows. I also had to use the pre-processor to call the Intel extensions equivalent to sleep(3c) and usleep(3c) which apparently are not available using icc(1) as the C co-compiler (it was the first time building that library in a pure MSWindows environment. Not usually a MSWindows user accept via Cygwin or ULS or Msys2 so had some other things to change technically unrelated to your CD/CI utility).
Now I need to sort through all that and tidy it up and then theoretically just copy it to the other fifty or so, as they are already set up to do a “fpm test” as their CD/CI process.
Still not sure why I needed to make some of the changes for fpm to work. Did I have to turn off -fPIC on MSWindows or should I change the loader to use PIE or PIC, perhaps? I was surprised I had to explicitly add /fpp or -cpp instead of .F90 working as a flag to pre-process (although MSWindows is not case-sensitive in some respects, so maybe that is not a common convention in MSWindows?) and so on. So I will probably change CI.yml to be eight different simpler scripts I think; but use anything you find useful in it as it sits; as it is all public domain or has a very liberal MIT license. Since the example program and test framework M_framework load a lot of other fpm repositories that is exercising quite a bit of code, so your setup of the environments is looking very good; I just need to sort through the fpm and compiler/loader issues that got raised as a result of your setup working!