Gcc devshell

[jacg]

Adds a second devShell which uses gcc instead of clang. This means we can now do

1. nix develop <path-to-flake>
2. nix develop <path-to-flake>#gcc
3. nix develop <path-to-flake>#clang

1&3 give a clang environment, 2 gives a gcc environment.

This could be useful for users who have a strong preference, but, above all, for allowing us to test both gcc and clang on GHA.

However, I'm unsure about how we should organize the workflows? Specifically, should the gcc and clang tests be run in

1. the same job
2. two separate jobs

?

• Pro 1
  • trivial to set up
  • uses less CPU and network (doesn't need to boostrap the GHA environment twice)
• Pro 2
  • reports gcc failures separately from clang failures
  • runs in parallel, so completes more quickly

Note: this sits on top of the as-yet-unmerged #82.

Closes #17.

[jacg]

FFS ... allow-fail has meaning in the GHA matrix. Why am I miserably failing to find any documentation on it?

[jacg]

... because it doesn't have meaning in GHA, I invented it as a convenient name (for use in continue-on-error) it would seem.

[jacg]

We now have this matrix:

    continue-on-error: ${{ matrix.devshell == 'gcc' }}
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-22.04, macos-12]
        py: [311]
        devshell: [ clang, gcc ]

so 4 jobs run (2 OSes x 2 compilers), and those on gcc are allowed to fail.

Curiously, the gcc job only fails on Linux, not Darwin. Is this because on macOS we're compiling with clang, even when in the gcc environment?

One slight wart is that we run nix-shell on both compilers' jobs, but nix-shell always uses the default (clang). It should be easy to switch it off on gcc.

[gonzaponte]

Just this one thing

[gonzaponte]

we're talking about at test that is spuriously passing and has just been merged in #82?

Yes.

[jacg]

I've lost track. Do we want to do anything more with this, or shall we merge?

[gonzaponte]

We want to skip the test, right?

[jacg]

I must be missing something: I don't see what this test has to do with this PR. What's more, it seems to be failing on master.

[gonzaponte]

I don't see what this test has to do with this PR

Ugh, nothing. I got lost in the many conversations. This can be merged.

it seems to be failing on master.

Ugh x2. Now I'm puzzled.

[jacg]

I got lost in the many conversations.

Yup, me too.

[gonzaponte]

it seems to be failing on master.

Ugh x2. Now I'm puzzled.

I'm trying to undo the set -e in my remote. If it works I will push it to master and we will deal with that on #88. But that shouldn't stop this from being merged.

[jacg]

I've just push a disabling of that test. It's getting in the way too much, right now.

[gonzaponte]

I'm trying to undo the set -e in my remote. If it works I will push it to master and we will deal with that on #88. But that shouldn't stop this from being merged.

I've also pushed this.