I contribute to both scipy and conda-forge (the latter more than the former), and the “best bet” for dealing with fortran (on windows; unix is doing fine with gfortan) we have currently is the upcoming flang(-in-LLVM).
I think we’d be quite open to bump the fortran compiler (in conda-forge) aggressively if that’s required for building packages (and doesn’t unnecessarily remove old platform/ABI support). Anaconda does not have the same restrictions as conda-forge; i.e. they can also use the intel compilers (in addition to what cf has).
I help with keeping the LLVM stack in conda-forge up-to-date (so availability shouldn’t be a bottleneck), but the biggest issue currently is that flang is not yet ready for prime-time (lacking code generation, as I’m sure most people here are aware). Hopefully things get ironed out enough until LLVM 15 to start compiling some packages and reporting eventual bugs, so that perhaps from LLVM 16 (in about a year) we can start using it more widely.
For completeness, we currently have flang(-original) 11 available already for windows, and gfortran on unix in all relevant versions. To be fair, the “globally” used version is still stuck at flang 5 on windows, though the only hold-up there is some required infrastructure work.
PS. I still haven’t fully groked LFortrans place in all of this, but AFAIU it won’t be able to replace flang in this.
Awesome, thanks for the note! Thanks for maintaining LLVM in conda-forge, I use it quite often and indeed it works great.
We (talking with my LFortran hat on) definitely plan for LFortran to work out of the box for SciPy and other packages on all platforms. We do not aim to “replace flang” or any other compiler, but rather if a user chooses LFortran, for it to just work. There will always be other choices. In your opinion, why wouldn’t LFortran be able to work for SciPy?
It’s certainly not a substantiated (much less authoritative) opinion.
My reading of your answer I linked in the other thread was that LFortran is more focussed on the interactive usecase. If it can be used as a fully-independent fortran compiler then there’s no reason in principle against being able to use it to package software for conda-forge, though it would likely have to outperform flang in some way, because we try to stick with one compiler per language/platform (to keep our already-large build matrices from exploding even further).
Sidenote: From a 100’000 foot view (i.e. ignoring many intricate differences/details because I just don’t know the respective projects nearly well enough) it would IMO be awesome if LFortran/flang could somehow be unified - at least to the extent that having a common infrastructure would accelerate (rather than hinder) the pursuit of each project’s individual goals (and maybe that’s simply not the case, but one can dream).
@h-vetinari Thanks for the pointers to the conda-forge Fortran toolchain on Windows. My current plan for Minpack on conda-forge is to use the old GFortran/MinGW 5.3 compiler rather than classic flang to build on Windows once we release it.
So far the Fortran compiler situation on Windows really put a stop towards Fortran projects I can package for Windows with conda-forge. Sometimes I can make it work with extensive patching and removing of modern features to get it working with GFortran/MinGW 5.3, however this doesn’t feel sustainable in the long run. The classic flang on the other hand, I never was able to get running even for the simplest programs.
Still, not much improvements on the Fortran on Windows front unfortunately. For fpm we still just repackage the binary from the GH release, but I’m looking forward to replace this with an LFortran compiled version soon.
Using an unholy combination of MSVC & gfortran. Which is why we’ve been waiting for an open-source Fortran compiler with bated breath for years.
It’s become much more acute now because scipy’s switch to meson forces a coherent toolchain (which MSVC + gfortran is not), so currently we’re playing catch-up, but llvm-flang isn’t ready yet, and neither is lfortran AFAIK.
LFortran can’t compile all of SciPy yet, but it can already compile Minpack and some other files in SciPy. We have funding to compile the rest of SciPy. If anybody here is interested to work on it, please get in touch with me.
