Add initial GitHub CI #30
Conversation
|
Cool, now the CI runs. (It fails, because gfortran is not installed.) |
|
First, I requested to include gfortran by default at actions/runner-images#202. In the meantime, we need to install it by hand. |
|
Things install on Linux now and tests pass. Now we need to figure out how to install GFortran on macOS and Windows. |
|
I guess we have to install our own Conda on macOS and Windows. |
|
It's going to take some time to get this PR ready. In the meantime I contributed just the Linux build in #33, so that we have at least some kind of testing. |
|
@certik Do we have to use conda? I'd rather just use pip, pipenv, etc. |
|
I'd recommend not using conda, except maybe on windows... Is flang from conda F18, or "legacy" flang? I have a lot of experience with CI, so I may submit a competing PR, at least to get macOS up and running and some odds and ends for macOS and linux. |
|
@zbeekman can you submit a PR getting Fortran working on macOS and Windows using Github Actions? That would be super helpful. We don't need to use Conda. |
|
I'm happy to submit a PR.. I'll start with mac and linux, windows will take some time for me to figure out... namely, which compiler to use and how to install it? (Cygwin? Msys2? Mingw? WSL?) |
|
(On windows I always use Intel, which is hard to do on CI) |
|
Linux is already done. If you can do just macOS with gfortran, that would be super helpful. Then we'll go from there.
…On Sun, Dec 22, 2019, at 10:47 AM, zbeekman wrote:
I'm happy to submit a PR.. I'll start with mac and linux, windows will
take some time for me to figure out... namely, which compiler to use
and how to install it? (Cygwin? Msys2? Mingw? WSL?)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#30?email_source=notifications&email_token=AAAFAWC24YAHIJRE243Z66DQZ6R2BA5CNFSM4J6JGAGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHPV7DY#issuecomment-568287119>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAFAWEDQMXTSBJPMXRF5KTQZ6R2BANCNFSM4J6JGAGA>.
|
|
Can I get us a newer gfortran on Linux? And a newer CMake? We should be using 3.14 at least for submodule support. |
We have to extend our CI to test with newer and older gfortran, so yes (in addition). Regarding CMake, I would suggest to require the oldest possible version that still works. Right now we do not use submodules, so I would not require a newer CMake until we need some feature from it, and then we can discuss if it is worth dropping older version support. That's related to #15. For submodules we would need to investigate the compilers that we want to support if they actually support submodules. Either way, I suggest you submit several PRs that are small, so that we can reach an agreement quickly and merge it (as opposed to a large PR with a complicated CI system). The most useful PR right now would be to get just macOS working. The PR can look like #33, but it installs gfortran on macOS instead. The second most useful would be a PR for Windows. Probably the mingw-w64 from msys2 is the most "native" solution. Once we have all three platforms covered, then we can extend our CI to test multiple compiler versions, as well as different compilers (Flang, and perhaps even Intel). |
|
Installing CMake binaries is so trivial I think it's worthwhile using more up-to-date versions. You can download statically linked, re-locatable binaries for all major OSes. I'll start by opening a PR with multiple versions of GFortran for Linux and mac, then I'll look into windows... |
|
FYI, your loadtxt CMake doesn't work with out of source builds. |
|
Yes, we need to fix the out of tree builds and test them on the CI
On many HPC systems they either do not have an internet connection, or if the do, they do not like you to be installing binaries from the internet. So being able to install using the preinstalled CMake and Fortran versions is a huge plus. In order to increase chances that things just work with default pre-installed versions, we should only require a newer CMake if we absolutely need the latest features. Besides submodules, which other feature do you find useful in newer CMake? |
|
On all the HPC systems I've ever run on grabbing a statically linked binary and putting it in my home directory has never been an issue. I check the GPG signature and cryptographic checksums and I'm off to the races. There are a number of features that I like in newer CMake and I can't keep track of which version each was added in. For example, I think it's nice to declare a target and then add sources to it later. There are also bug fixes for If it's decided not use a suitably new CMake I probably won't be motivated to contribute. Why use CMake at all then? Why not just use Makefiles? We're already handy capped as we wait on compiler vendors to implement or fix new Fortran language features and I don't see a compelling reason to not use a suitably Fortran aware build system. If people are "just grabbing sources and putting them in their build trees" then it doesn't matter whether or not they're allowed to grab CMake binaries. |
|
@zbeekman thank you for improving the CI build system. You have a good point that since I think we'll probably decide to maintain manual Makefiles at #36, we might be able to get away with requiring the very lastest CMake, as for people who don't have the latest CMake, they can just use manual Makefiles. Let's move the discussion to #41. I am closing this PR in favor of #39. |
TODO: