Until now the build and package scripts have supported
several architectures, compilers, build types, package-managers,
and bit-depth targets.
The code might be maintainable if left as-such, however we have plans
to continue expanding the number of architectures (ARM, PPC, ... ),
operating systems (Android, BSDs, ...), and build variations
amung those.
The scripts (regardless of language) would only grow in complexity
as more variations are added. Thus, we needed a solution that can
scale without adding complexity.
To achieve this, the scripts were refactored as follows:
- all "data" was moved out of code into configuration files
- A back-end "Automator" engine was written to parse the
data based on generic variables fed to it by a front-end
script
- build.sh and list-packages.sh were re-authored as thin front-end
scripts that drive the automator
- Their CLI's were retained so there has been very little change
needed to the CI invocation lines. The only changes have been to
clarify the existing arguments improved based on feedback, ie:
--build-type release, --build-type debug instead of fast, small
The commit makes the following changes:
- The package listing script now requires the user specify which package manager
they're using. This approach resolves the ambiguity if a system has more than
one package manager (ie: macports & brew)
- Adds packages for Fedora, RedHat/CentOS, Arch, and OpenSuse
- Eliminates unecessary code in the package manager script
(more can be eliminate at the expense of complexity)
- Made a couple minor fixes to the build script
- Tried to further "standardize" the workflows as follows:
- names are Compiler Version (Environment)
- Sorted them alphabetically in their respective YAMLs
- Minor spacing adjustment to align values (where it makes sense)
- Dropped quotes around some of the string values because I'd
rather our YAML be consistent and propper instead of changing our
YAML to suite the limitations of an editor (can a different plugin
or better parser be used?)
- Added macOS workflows for Homebrew and MacPorts, both ready to
go and tested, but with the build step just commented out
This change makes a couple changes to the CI workflow:
- Adds more compiler coverage:
- gcc to MacOS (see note below)
- 32 and 64bit gcc and clang to Windows
- With more builds, this separates them into per-OS workflow YAMLs
(laying the foundation for more build environments: BSD? DOS? ... )
- Moves all functional commands from GitHub-syntax-YAML into scripts,
which (besides eliminating repeated code), now serve a dual-purpose
of being runnable outside of GitHub.
- One script takes care of listing dependent packages for the given
runtime environment
- Another script takes care of configuring and building
These scripts can be leveraged by a nightly build & asset generator in
the future.
Note: adding GCC to MacOS is now "correct" from a build perspective,
however to keep this PR focussed on the CI workflow I have not included
the coreMIDI / AppleBlocks code-fixes here (so for now, the gcc macOS
builds will fail; we will merge the coreMIDI / AppleBlocks later
depending on how upstream wants to handle it).
