Build: Do not run two builds in one GitHub Actions Job

[ann0see]

What is the current behaviour and why should it be changed?
Jamulus for macOS (and Debian) is being built in one job twice. There are some issues:

1. macOS server and client binaries are basically almost the same. There's no technical need to have two almost identical binaries installed. JamulusServer.app should call Jamulus.app with the -s argument (maybe with a script or something smaller than a full Jamulus build). This might imply some changes in the build process - and should still not have visible changes for the user.
2. The debian build consists of headless and gui builds which are both being built in the same job. CodeQl might not be able to detect two builds

Describe possible approaches

To 1: Provide a small .app which calls Jamlus.app with the -s argument (probably Automator could produce this app). However we should still allow the user to "only copy the server to his applications folder" (not sure how we handle this)
To 2: Maybe parallel builds could be implemented

Has this feature been discussed and generally agreed?
No, but see @hoffie s comment #2476 (comment):

Running Jamulus.app with -s might be possible (I haven't investigated where this "starter" is defined). Right now it is being implemented with a define (SERVER_BUNDLE) which changes the behavior of the actual binary.
I think both this case and Linux (HEADLESS) is problematic for building in a single go.

[hoffie]

To 1: Provide a small .app which calls Jamlus.app with the -s argument (probably Automator could produce this app). However we should still allow the user to "only copy the server to his applications folder" (not sure how we handle this)

Is there an equivalent of .desktop files on macOS? That would help here.

In case of SERVER_BUNDLE we could technically do selective cleaning. IIRC, the define is just used in main.cpp, so it would probably be safe to delete main.o and re-run the build which would effectively just recompile one source file and re-link. I don't really like that approach though as it mixes abstractions (we would have to remember to adjust this special logic if the define was used elsewhere).

To 2: Maybe parallel builds could be implemented

That would be consistent with what's done with Windows ASIO vs. JACK, so that would certainly be a solution.

[ann0see]

I think there's no clean way: https://superuser.com/questions/16750/how-can-i-run-an-application-with-command-line-arguments-in-mac-os

[softins]

The Android job builds four times, and this can't be avoided, as an Android package needs to contain binaries for four different CPU architectures. They need to be built in the same job in order to create the package.

[hoffie]

I think there's no clean way: https://superuser.com/questions/16750/how-can-i-run-an-application-with-command-line-arguments-in-mac-os

:(
Not sure if it's worth it then.

What we probably could do though is try to build those four architectures in parallel (different steps), upload them as intermediate artifacts and run the bundling (or whatever it is called) in another step afterwards. I have no idea if the qmake/Android build tooling is made for this (I suppose it's not) and I'm not convinced that it's worth the effort and the added complexity in the workflows and scripts.
I think we should optimize build times, but maybe just target the low-hanging fruits for now?

[ann0see]

I think we should optimize build times, but maybe just target the low-hanging fruits for now?

Agree.

[ann0see]

Moving to discussion as no solution is available at the moment.