supports all build-script options; save sets of settings for later recall
saves and replays prior builds; review logs of prior builds
supports all toolchain build-presets.ini features; assists in composing custom .ini mixins
live log streaming and progress monitoring
rebuild specific target dependencies; update dependency repos
built with SwiftXState actor-based concurrent statechart orchestration system with integrated statemachine 2D/3D visualization, event timeline, and state snapshot introspection interface
built-in psychoaccoustic 3D .mod/.xm/.it tracker music playback with dual AudioUnit effect inserts, powered by Ox0badf00d pure-Swift mod tracker
realtime introspection into BuildOperations state machine, which is orchestrated by a background actor
the machine monitors log output from the active build
state transitions are triggered if logs contain new build phase text to indicate the next module is being built/tested or that the toolchain is being installed, etc.
state changes stream from the background actor to a MainActor observable AppSession
UI updates based on bindings to the AppSession
thus a unidirectional state-flow is achieved
The XState-format JSON shows:
current state snapshot of the ongoing build process
How hard would it be for Apple to make SwiftUI, SwiftData, and AVFAudio support Linux
So that we can hopefully get some cross-plat efforts going... I've gone ahead and separated out all the cross-platform-capable code into a separate Swift Pacakge called SwiftRepoCore. That represents 37% of the total app—all the 'business logic' from macOS app that I could feasibly separate out... almost all the state machines, actors, data models, and services.
SwiftRepoCore has the following dependencies, both of which are cross-platform:
-SwiftXState (2.0 alpha, which adds the SwiftUI-like declarative state machine DSL) Note: SwiftXState also depends on swift-docc-plugin but it won't use it for normal builds when it's a dependency. It's just there for building the docs on CI.
-CompositionalInit (a very lightweight lib that came out of an old evolution pitch here, which adds "CasePath" and KeyPath-based initialization and functional cloning with mutations, used by the state machines to make targeted updates to state, without relying on any macros).
That leaves 5800-ish lines of code that need to be ported to create a linux/Windows/etc. version:
the SwiftData/SwiftUI code (we could omit the configurable colors/fonts; some of the eye-candy elements; and all the data persistence while still a functional app)
the Apple-specific audio API code from the music player lib Ox0badf00d (totally unnecessary to port at first)
If you feel like giving it a try, fork the main repo and start working on a Linux UI port. @codelynxposted back in March that they have made a Linux port of SwiftUI. The app does not use anything fancy in terms of UI, so it should be pretty straightforward to make cross-plat.
I'm pretty useless when it comes to linux development, but if you're not wanting to work on that let me know, I can give it a shot.
