Binary compatibility is one path, but another path is source / API compatibility. That’s been more or less a dream for a long while, with a fairly far along implementation:
But for whatever reason, it’s not really caught on. Even Mono managed to chase C# / .Net more impactfully than GNUStep has chased Cocoa.
Had GNUStep ever become more widely used amongst the Free *nixen, I feel like we could have had a credible, open alternative path to macOS/iOS (not to mention Linux) development.
Hello, I am one of the Darling developers. Yes, we would love more help! A good deal of command line-only stuff is working at this point. GUI application support is limited but we are making progress.
We are also looking to improve the experience of first-time contributors and we welcome feedback related to how we can make it easier to give you the information and tools you need to contribute to Darling.
I’m curious as to what the current state of the project is, as well as what kind of things you were working on. I heard that you can use Xcode’s toolchain to compile binaries now?
I'm glad you're interested. We really should write progress report blog posts or something, similar to Dolphin emulator or RPCS3. Yes, the Xcode command line tools should work for the most part when running in Darling. If you try to use Darling for development please create issues on our GitHub if an individual tool crashes or otherwise fails to work.
Unfortunately, git doesn't work at the moment, however this can be worked around by using Linux git since Darling works in your Linux home folder.
One cool thing that works is lldb, which for the most part fully works.
Darling also supports mounting disk images and installing .pkgs, which is really helpful.
In short, we support most of what you can do from Terminal already.
Homebrew and MacPorts currently don't but once we get them working they should make it easier to install packages in a Darling prefix.
We also have binary compatibility with standard Mach-Os from macOS.
Unfortunately, the other project members (around four of us) and me are often busy with our lives and don't always have the time needed to advance Darling, so we are exploring how we can improve outreach to attract more developers.
While we are similar to the WINE project in goal, at the moment we have nowhere near the resources they do, so it is difficult to accomplish our goals.
> We really should write progress report blog posts or something, similar to Dolphin emulator or RPCS3.
Sure. I’m already pretty happy with the informational blog posts you have already; the linker one that was posted earlier this year was quite enlightening.
> we are exploring how we can improve outreach to attract more developers
No promises, but I might take a look sometime.I currently have easy access to macOS so I generally don’t have a good reason to run darling, but if I ever do and I run into a bug that annoys me I’ll see what I can do to help.
I'm quite interested in Darling, mostly for the purpose of cross-compiling from Linux -> Darwin. We cross-compile a lot of things for Julia, however cross-compiling executables that need to bootstrap something, (e.g. building something that then needs to run to generate output which is then used in further builds) can often get tricky. There are of course workarounds that can be utilized in order to get this to work (build a Linux-native version and a Darwin version, then use the Linux-native version of the software whenever a bootstrap is required) but this is tedious and not foolproof.
I prefer VIM as my editor but when I write iOS/Mac apps I just suck it up and use XCode (with vim key bindings). While building apps outside of Mac would be cool I think you'll always find most engineers getting sucked back to XCode unfortunately. It is so verbose that I find the integration XCode has with the documentation to be super helpful. I'm sure you can get this with other IDEs but if it's not VIM it might as well be XCode for me…
I hate IDEs. I’m sure I’m not the only one. Graphical interfaces are not optimal compared composable command line interfaces, nor is the mouse/trackpad an ergonomic input device.
It's not a matter of mere preference when using non-ergonomic devices results in debilitating injury (carpal tunnel syndrome) which prevents me from working.
With vim bindings are you still having to manually strip out xcode's code signature to install the plugin? That was the state of affairs last time i tried to do it.
Yeah, you still have to resign with your own thing in the keychain. It’s kind of weird and it caused me to hold off for a while. Eventually I caved in because I can’t stand using the mouse so much.
I think this would be much harder because Linux is a monolithic kernel and doesn't allow subsystems the same way Darwin does since it is a hybrid kernel (like NT)
All binfmt does is allow exec() and friends to run a custom wrapper program; for example, qemu or wine.
Windows / NT subsystems (and specifically, here, picoprocesses), effectively intercept all entries into kernelmode from a particular process; when you execute a syscall instruction, the kernel invokes subsystem-specific code.
https://en.wikipedia.org/wiki/GNUstep
But for whatever reason, it’s not really caught on. Even Mono managed to chase C# / .Net more impactfully than GNUStep has chased Cocoa.
Had GNUStep ever become more widely used amongst the Free *nixen, I feel like we could have had a credible, open alternative path to macOS/iOS (not to mention Linux) development.