First of all, the RPM packaging code hadn't been updated in quite a
while (it was still using the LKM), so this updates it to build with
darlingserver instead of the LKM.
Second, this update also adds a dependency generator that is used at
build time to automatically pick up the ELF dependencies in installed
Mach-Os. I prefer Debian's approach to this (simply having the option to
dynamically generate the requirements into a file at build time). This
seems like a convoluted approach (having to install a `fileattribute`
globally on the build machine), but at least it works.
Finally, this update also splits the package into multiple component
packages like the Debian packages. Note that `darling-cli-devenv` needs
to install files with the same names as those installed by
`darling-gui`, so it has to be built as a completely separate package. To
avoid having to rebuild a large portion of the project (about 8000
files), we simply generate a binary "source" tarball when building the
main Darling packages and then use this as the source for
`darling-cli-devenv`.
This is necessary to install files to the right directory when doing
single-component installations (as used by binary packaging) since the
`/etc` symlink is only installed by the `core` component.
This new build setup allows you to only build and install certain
components of Darling according to your needs. The primary motivation
for this change is to allow you to build Darling without any GUI
dependencies if you only care about or need the CLI.
JavaScriptCore is now excluded by default. This is a huge build item
that 99% of people don't need and we certainly don't use (yet).
There will be an update to the docs to describe the component options.
This is mainly used for the modular build, so that we have
dependency-free stubs for certain GUI frameworks that Xcode loads but
doesn't actually use in the CLI.
This service is used by Xcode when it crashes to help symbolicate the
stack trace. However, stubbing it to return empty dictionary replies
seems to be enough to get by.
A bit of a backstory: macOS Big Sur was the first version of macOS to increment it's major version number from 10 to 11. Since Apple doesn't want to break old applications that assume the "10.x" version scheme, they applied a small hack in the xnu kernel to have older applications read off of the SystemVersionCompat.plist instead. So instead of seeing "11.6", the app would see "10.16" instead.
Since the macOS deployment target was not updated to BIg Sur's version, sw_vers would report "10.16". Fixes#1334
