Build: Parallelize compilation on Android, Mac (CodeQL) and Debian

[hoffie]

Short description of changes

This PR modifies the make calls to use a -jN paramter to parallelize builds.

• Mac already used this.
• Windows' nmake doesn't support -j, but I'll try to do something similar using jom.
• This PR adds
  • Android
  • Debian
  • Mac (CodeQL)

CHANGELOG: Internal: Speed up Debian, Mac & Android build processes by using parallelization.

Context: Fixes an issue?

Performance

Does this change need documentation? What needs to be documented and how?

No

Status of this Pull Request

Ready.

• Linux build times are down from 8m22s on master to 3m51s in this build
• Mac codeQL build times are down from 10m13s on master to 6m59s in this build
• Android build times are down from 32m28s on master to 24m0s in this build

Note: Build times do vary so take these numbers with a grain of salt.

What is missing until this pull request can be merged?

Reviews.

Checklist

• I've verified that this Pull Request follows the general code principles
• I tested my code and it does what I want
• My code follows the style guide
• I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
• I've filled all the content above

[ann0see]

Interesting it works. I tried it once and the CI ran out of resources. But if it works now that’s great (I.e the build time gets ok-ish time wise)

[hoffie]

Interesting it works. I tried it once and the CI ran out of resources.

Maybe hardware specs have changed (Mac seems to use 3 cores, other platforms 2 cores) or another -j value had been chosen in the past? As said, the Mac builds already used this, so it didn't break anything at least.

But if it works now that’s great (I.e the build time gets ok-ish time wise).

The examples show an improvement, but there is lots of flakiness in build times, so it's hard to tell for sure and how much the benefit is. Anyway, some of the build scripts are also used locally and not only in autobuild, so it makes sense to add it anyway.

[ann0see]

I think @pljones or I used plain -j

[pljones]

Build is green (but I still get confused whether it's using the "to be merged" CI components when doing CI on CI components or whether it's using the existing ones).

[ann0see]

I think it uses the one in the PR.

[hoffie]

I think @pljones or I used plain -j

That's what I use locally as well. I thought it had some automatism for figuring out a good N value, but it seems like it would just start anything it could ("similar to a fork bomb" is what I read elsewhere). So that might explain it.

but I still get confused whether it's using the "to be merged" CI components when doing CI on CI components or whether it's using the existing ones

Pretty sure it's the to-be-merged ones. Besides .github/, Github has no way to figure out what else is "CI related". I think you might be referring to the logic that PRs (pull_request event) do not run in the security context of the target repo (jamulussoftware/jamulus). IOW, they do not have access to a GITHUB_SECRET with repo access. See https://securitylab.github.com/research/github-actions-preventing-pwn-requests/