This is a request for help, though hopefully any help will feed back into our larger communities.
I maintain a Fortran code for computing the flow of radiation (light) through Earth’s atmosphere. In normal practice users build two sets of libraries, one for a modern Fortran front-end and another for numerical kernels with C bindings, then link their own codes to these.
The code is mostly used on large computers running some variation of Linux. It would be more useful, though, if it were available for students and researchers on a wide range of platforms including Windows. What I’d really love is to distribute the libraries and Fortran module files via conda. But I have no experience with Windows and no access to a Windows development system.
I would be extremely thankful if someone were willing to help me adapt my Makefiles and scripts to a Windows environment, say so that I could start doing my continuous integration testing on Windows alongside Linux. This would also let me expand the reach of my Python front-end.
Knowing this is a lot to ask and a long shot… thanks anyway.
2 Likes
Hi @RobertPincus, I can have a quick look and see how big of a task it would be. Do I understand correctly that the commands to build the lib are make libs && make -C build separate-libs?
This might not be necessary, but would you be willing to swap the manually written GNU Makefiles with CMake or Meson, they tend to make cross-compiling and multi-OS compiling a lot easier.
From what I can tell you might be closer to getting this to compile under Windows and being shipped as a conda feedstock than you originally thought.
1 Like
@gnikit That would be lovely. To build the libraries alone (on branch develop which is what I’m targeting) is simply make libs. To include Windows in the CI would mean make libs tests check. The latter targets require some dependencies (netCDF) and cloning a data repository.
I’ve resisted CMake because I don’t use it myself in any other projects and the learning curve is a bit steep. There’s a branch autoconf maintained by the German Climate Computing Center but they may move away from this.
I have a build working version on a Windows VM with almost minimal modifications to Make/environmental variables.
The problem with autoconf, autotools and GNU Makefiles is that they are not really suitable for cross-platform applications that target non-UNIX-like OSs. So locating libs like netcdf and correctly setting up include and lib paths is bound to be an pain.
Thanks so much, excited to see this (I saw you had opened but then closed a pull request) and will share back to this forum what you teach me.
Yeah, apologies for the PR, it was accidental. I use GitHub’s CLI tool and I bungled up the remote I should be merging to. I will try and find some time this week to finish it.
@RobertPincus This should be done now. There is some strange behaviour with GCC 12+ and the Windows runners that I couldn’t get to the bottom of and is probably worth investigating.
@gnikit Thanks so much for this. I’m traveling this week but would like to summarize the experience in this thread when I adopt the changes.
To report back: @gnikit kindly provided a pull request for my Fortran repository. His life was made harder by the fact that building and testing is built for Linux with some small support for MacOS - i.e. we use Gnu make, hand-built Makefiles, shell scripts, etc. Giannis got around this by extending the CI to run on Windows and renaming executables and directories within the shell scripts.
We will adopt this in the short term but the awkwardness of the solution brought home that true cross-platform support for building and testing can’t rely on hand-built files and Gnu make, so we will likely transition to CMake and possibly CTest sooner than later.