While darwinbuild has served us well so far, as I work towards building an ISO from scratch (cf #38), I find that it is not well-suited for building a complete Darwin OS image from source. The main issue is that it is stateless. There is no way to tell a priori that a given project has already been built. Because of this, the only way I could implement darwinbuild -recursive is to blindly build all detected dependencies every time. This is wasteful of time if invoked repeatedly, as it has no way to tell if a project is up-to-date. As far as darwinbuild knows, it may be wildly out-of-date and therefore must be rebuilt, even though we know it was just built two minutes ago by a previous darwinbuild invocation. Furthermore, the use of darwinbuild plists to orchestrate the build does not work well with any sort of CI system; it is also IMHO a very chaotic method to handle versioning of dependencies. All the changes made to PD18_2.plist also required a tag be made in the source repository, a completely ad-hoc and non-standardized process.
In addition, I am growing personally disillusioned with the increasingly locked-down nature of Apple macOS. As a result, I was looking into ways to potentially build PureDarwin without needing to use xcodebuild, as Xcode requires the use of macOS. (Yes, there is xcbuild, but while it once showed promise it is now so bit-rotten that it no longer works at all due to changes in Xcode; furthermore, even when it was comparable in functionality with Apple xcodebuild, it had a nasty habit of segfaulting.) The Darling project uses CMake to build a Darwin-esque environment (everything but kernel-mode) from source using CMake. While one benefit of this technique is that it works on Linux as well on Darwin/macOS, I feel that moving PureDarwin to a build system like Darling's (using CMake and possibly a vendored copy of cctools/ld64), and using submodules to organize the code would have benefits even if we stick to building PureDarwin on macOS (or itself!) only.
If this proposal is accepted, I would start work by creating an "SDK" repository that contains the common CMake modules that handle things such as cross-compiling or processing MIG files, as well as a copy of the headers and *.tbd stub library files that are used to build an arbitrary PureDarwin component. (This would essentially be a freely-licensed version of the Xcode MacOSX.sdk directory.) I would then add CMakeLists.txt files to the various repositories under the PureDarwin organization. Once that's done, I would add those repositories as submodules under the projects/ directory. When the root PureDarwin repo is cloned, the SDK would be included as a submodule and the other projects would be pointed to it via a CMake variable. (If a component repo is cloned on its own, for example in a CI scenario, then the SDK would need to be downloaded separately before the build and CMake given its location manually.)
The build process for XNU would not change much. XNU will still be built using the existing Makefile-based system, integrated into the CMake build using the ExternalProject system. Its dependencies (dtrace, libdispatch, and a few others) would be built using CMake, and passed into the XNU makefiles using a file containing paths generated using the CMake configure_file feature.
Tell me what you think!
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent