I’m looking for an easy way to create a stand-alone environment for a classroom-type setting, where I can install gfortran and other useful tools on Windows machines. I was going to use conda, but it seems like there are no Windows binaries for gfortran available. Users will not have admin rights, so can’t run any installer that requires that, everything must be installable in their local user directory, it shouldn’t mess with any system paths, and when they are done, it should be something that can easily be deleted.
Conda seems ideal for this, but not sure how to get gfortran. Is there a channel somewhere I missed that has it (a fairly recent version).
Oh interesting. I tried it, but unfortunately it installed flang 5.0.0. Not sure of the state of this or if it’s “new” flang or “old” flang, but it doesn’t seem to be able to compile code that has more recent language features that I rely on.
Conda-forge has GFortran/MinGW, I think it is based on an early attempt to distribute MSYS2 via conda. What you get is GCC 5.3.0 and can be somewhat shaky depending on the features you want to use in modern Fortran.
Alternatives, beside the quickstart installer might be
Nobody decided to do it yet, simple as that. It is not a nice task, you will have to patch the compiler until it passes its test suite, than you have to rebuild all existing packages using this compiler (only in case of an ABI change), if something fails probably patch the package build and/or the compiler build.
It just takes a lot of effort and conda-forge is just like Fortran-lang entirely driven by volunteers. Helping hands are always welcome!
The workflow for a compiler update on conda-forge is outlined in
Another choice may be using Docker. You can install and configure whatever you want in the Docker image. People just need to load that image and bingo.
Or, I think you can also create a WSL image with GUI configured, and people can load that WSL image, and visit it using Windows Remote Desktop via the port you defined in that image (such as port 3389, 3390, etc).
But of course, in the above two cases, users are still using Linux actually. But Gfortran performs the best in Linux.
If you make the students use Visual Studio Code it should be able to integrate natively with the WSL environment, no virtualization from within WSL. BTW The same is true for docker images, although you might need the remote extension pack from Microsoft
I always recommend MSYS2 (winget install msys2.msys2), because in addition to the GCC suite, we may also need other tools, such as lapack/openblas, hdf5, git, python, etc., which can be easily obtained in MSYS2. After installing MSYS2, we only need to set the the environment path of the execution program can be: C:\msys64\ucrt64\bin, that you can access the MSYS2 environment in cmd and pwsh.
Other than that, Cygwin (winget install Cygwin.Cygwin) is also possible, but as far as I know, MSYS2 seems to be based on Cygwin under the hood, so I think there may be no essential difference between MSYS2 and Cygwin, but MSYS2 is more convenient.
Cygwin has a much more complete *nix environment easily available with hundreds (thousands?) of additional packages and X11 Windows; but with the other options available and depending on whether you also do/do not want them to have a Unix-like interface and X11 windows it might not be what you want. I adore it, but there are a lot of other options, as mentioned. Works great with fpm(1) too, but so do some of the others.
Thank you for that. I totally understand it that volunteers don’t always want to do the thankless tasks! I wonder if some of the ongoing activities to try and get funding could be applied to this? Being stuck with older compilers is a continuing problem for the Fortran ecosystem, and Windows is an important platform for beginners, students, and potential corporate users.
Anyway, a question: what if we just wanted a gfortran we could conda install, but don’t care about recompiling all the existing packages? Would that be a smaller task? The gfortran used by quickstart-fortran is from WinLibs. Maybe I could create some recipe to just dump it in an env? Or does that not make any sense? For my classroom example, I just want a conda env file that will install a recent gfortran, python, and probably matplotlib (so I can use pyplot-fortran to show how to plot from Fortran), maybe a couple other things. Would the presence of a rogue gfortran in the conda environment conflict in some way with what was used to compile some of the libraries (numpy or lapack maybe)?
I haven’t touched compilers yet on conda-forge, I can’t tell for sure if this would be easier. They are mostly split packages, with a compiler, a wrapper and a runtime. The issue is the runtime which might not be compatible with older versions and therefore conflicts with installations of older runtime versions.
The rebuilding after such an update is mostly automated, the problem are the 5% of packages which might fail, those can be mostly fixed in the respective package recipe. Since we are talking about 17k packages on conda-forge and an update affecting the fraction which uses GCC for C, C++ and/or GFortran and Windows, it is best to coordinate such effort with the conda-forge core team.
I think Brecht Sanders never shared his setup for building WinLibs.
Conda environments provide enough isolation to make this work. You can have completely different and conflicting runtimes for some programs if you have them in different environments, then you can just stack them on top of each other and things should usually work. Cross-linking or cross-loading libraries between such environments will be a bit more tricky as you try to break the environment isolation.
At GFortran - GCC Wiki several options to download gfortran binaries are discussed. I have not tested these downloads (on Windows I use MSYS2). Note that for these solutions OpenCoarrays usually is not included, so the use of Coarrys may be be limited to a single image.