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.
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
The new `ENABLE_METAL` option can be set to `ON`/truthy, `OFF`/falsy,
or `AUTO` (the default). When set to `AUTO`, Metal support will only be
enabled if LLVM and Vulkan are available.
Note that even if Metal support is compiled-in, Metal will only be
available at runtime if LLVM and Vulkan are available. This also means
that you can build Darling on a host with LLVM and Vulkan available and
install it on machines without these libraries available with no issue
(the only effect would be that Metal would be unavailable at runtime on
these machines).
Implemented CMake methods for:
* Deleting the old headers before generating the new headers.
* Updating the "Developer" and "framework-include" headers.
* Generating the private frameworks headers into their proper dedicated folders ("PrivateFrameworks" and "framework-private-include")
Updated multiple frameworks to take advantage of this feature.
This commit includes support for Mach port filters in kqueue (via the new kqchan facility in darlingserver).
Additionally, ccache usage can now be disabled via DARLING_NO_CCACHE.
Previously, we were just using Linux's passwd, which caused inconsistencies, e.g., with home directory lookups.
Now, we also add the user to /etc/master.passwd so programs running as fake root within the prefix can still look our user up (since libinfo checks /etc/master.passwd when running as root instead of /etc/passwd).
...and use it in the various printing functions, instead of `__simple_vsprintf`. This fixes some buffer overflow issues with really long messages (like for applications with long path names when logging the execv expansion message).
Also, install an empty `/Library/Preferences` directory.
The main goal of this commit is to make it more easy to add or update any architecture we want to support (such as ARM64). Any changes we want to make would be done in the architectures.cmake file.
The secondary goal of this commit is to encourage a more architecture generic nomenclature. We shouldn't use i368/x86_64 unless we are dealing with code that is specific to those architectures.
* Create ccpp.yml
use git remote set-url
run makedeb
add ccache
add devscripts
use ccache if possible
src before made
* Update ccpp.yml
* move ccache and different debug
* naming
* add artifacts
* try with a cp
* try escaping? now regex might now work
* try moving to debbuild
* move and compress debs
* try seperate jobs
* try getting source in, probably too big
* fix name
Currently x86_64 or i386 only builds fail to enter shell.
CMake generation flags:
Build x86_64 only: -DTARGET_i386=OFF
Build i386 only: -DTARGET_x86_64=OFF
The default is still to build FAT binaries for both.
This greatly speeds up build time when enabled.
For now it disables building JavaScriptCore. Use it like this:
cmake .. -DFULL_BUILD=OFF
To enable large items again, do:
cmake .. -DFULL_BUILD=ON
By default it is ON.
This fixes#391.
