Support for ArchLinux Build

[karlovskiy]

Added support for building project on arch linux in addition to ubuntu.

[anders94]

Haven't tried it on ArchLinux but the logic LGTM.

[HalosGhost]

I'll happily take a further look (I actually have several Arch machines, so it's easy for me to test :)), but this is missing a DCO.

[karlovskiy]

I've added a missing DCO. Script is working on my arch machine, installed libs (excluding base-devel):

wget-1.21.3-1
cmake-3.25.1-1
gtest-1.12.1-1
lcov-1.16-1
git-2.39.0-1
rsync-3.2.7-3
llvm-14.0.6-4
clang-14.0.6-4

[anders94]

I'm not seeing anything in that last commit...

[karlovskiy]

@anders94 I've changed commit message and force pushed it, I see now that All commits are signed off! and that DCO check is successful.

[anders94]

LGTM

[HalosGhost]

concept ACK. Running full CI now (unlikely to break). I'll test locally shortly (might be a few days since I'm still on Winter-break). But here's a question I have (this is an open question, so looking for opinions): should we add a CI step for Arch to test it (if it's going to be a supported platform, that's a great way to know if something breaks on it for changes to other platforms)? More generally: should we always add a new CI step to test on newly-supported platforms? My immediate feeling is "yes," but I'm open to counter-arguments.

[anders94]

IMHO an Arch CI makes sense at the cost of both whatever the CI runs cost and the cost of taking on Arch maintenance going forward. My $0.02 but I'm not the one paying the tech debt on this! :)

[HalosGhost]

Thankfully, GitHub CI is free for open-source projects, so that part isn't a specific concern for us. The technical debt is what would worry me more of the two, but I already use Arch, so it's kind of semi-maintained anyway.

I think the thing I'm concerned about is more about the iteration cycle: to actually have arch be tested, the full test suite should be run on it which will increase the runtime of the CI by 100% of the time for the test suite for each newly-supported platform. I don't love that…

@karlovskiy would you be comfortable/interested in adding the CI build-steps for Arch?

[karlovskiy]

Hi, unfortunately I don't have enough time to implement this. I've added and tested the build on arch locally and my thoughts was to share this with you (maybe it will be useful for someone else using arch) like it's for MacOS build. As I understand, macOS also doesn't have CI build steps. Supporting arch with all CI stuff is IMHO a tricky path.

[HalosGhost]

Yeah, macOS is also kind of semi-maintained (because several contributors use it). I'll mull on this for a little while and see if I can figure out a reasonable path for adding a new fully-supported architecture.

[HalosGhost]

https://github.com/cross-platform-actions/action Leaving some art I just stumbled across a a potential avenue for a solution (allowing running a single github action across multiple operating systems).

[maurermi]

CI support for macOS alongside Ubuntu could be added using something like that below, which would run the build-release workflow on both Ubuntu-20.04 and the latest version of macOS. However, this does not solve the issue of adding Arch CI support.

jobs:
   build-release:
     name: Build Release Candidate
     strategy:
         matrix: 
             os: [ubuntu-20.04, macos-latest]
     runs-on: ${{ matrix.os }}

[HalosGhost]

@maurermi just to double-check my understanding. Do you mean it doesn't solve adding arch support because configure.sh also needs to be modified (as in this PR) to add support for it, or do you mean something else?

[maurermi]

@HalosGhost I mean to say that GitHub does not host any runners for Arch Linux, but they do for macOS (+ Windows, Ubuntu). Seems like a custom runner would be needed for Arch.

https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources

[HalosGhost]

That's a really unfortunate nail in the coffin for that idea. @karlovskiy so, without our CI having support for arch, I don't think it's possible for us to make it fully-supported in a sensible way. I don't think we have a good story figured out for maintaining configure.sh for unsupported platforms. However, because we do have team members who use it, it's in a very similar vein as macOS right now.

To that end, if you want to fix the merge conflicts, I'm still comfortable merging this.

[HalosGhost]

I'm closing this for now, as I think the only sustainable way for us to officially support additional platforms is if they are included in our CI.

This is not a dismissal of other platforms, and bugs/issues reported for other platforms will still be reviewed!