Continuous integration

[mschubert]

Are you interested in a PR to set up Github CI for the build?

[rcedgar]

Never used CI, looking at the docs I guess I'm a bit skeptical, looks like one more thing I would have to learn and I don't see any benefit it would bring to this project. By all means educate me if I'm missing something.

[mschubert]

Happy to explain!

The idea is to make sure that muscle can be built from the source that is available in this repository, on a range of standard platforms.¹ Trying to build the last release, there were a couple of (minor) issues that it could have easily warned you about:

• Build failure because of missing counter.h file Missing counter.h file #8 (or future files you may forget to check in)
• Build failure when ccache is not available
• C++11 standard on current gcc compilers -std=c++11 CFLAG needed in Makefile #4

These are minor issues, but they are something every package for a (e.g.) Linux distribution has to repeatedly solve if it is broken in this repository. It makes sense to follow a set of standard practices to ensure compiling the software works with the standard tool set (e.g. gcc, clang) on a broad range of OS's.

What I'm suggesting is to send you a Pull Request that contains a Github Actions file to build muscle on some standard OS's every time you push to the repository.

You would not need to learn anything new, because I would provide the file (and it's straightforward to read). The workflow would alert you if the build does not work for some reason, e.g. the reasons listed above. If, for some reason, you decide you do not want this or it causes you trouble, you can simply delete the file again.

And of course it would reduce the likelihood that package maintainers each need to apply their separate patches to the build system.

---

¹ This could also include running tests for your software to ensure it is working correctly (and prevent regressions where a feature is accidentally broken)

[joelb123]

I agree with what Michael said, and I think we should simply start pull requests to you so that you can see how easy it can be to collaborate on something. CI testing and packaging enables you to be more productive by automating the tedious stuff while ensuring that contributions from the community don't break your code.

As an example, on Muscle v4 I found that native compilation on gcc-11 with program-guided optimization gave more than a factor of 2 improvement in performance over pre-compiled binaries on my platform. I've been reluctant to give those simple makefile changes because the CI infrastructure isn't there for you to easily test them.

[rcedgar]

Sorry for long delay, thanks for the explanation -- this sounds like a good thing to try if you guys can set up the github actions @joelb123 @mschubert

[rcedgar]

I tried to set up workflows for building, please see PR #17. I'll wait a couple of weeks for comments before merging.

[rcedgar]

Implemented in v5.1.