Open coolbluewater opened 3 years ago
Using osxcross I can get this far
user@ubuntu:~$ zig cc -E -ObjC -o hello hello.m -target x86_64-macos-gnu --verbose -E --sysroot ~/Desktop/osxcross19/SDK/MacOSX10.15.sdk
clang version 11.0.1 (git@github.com:ziglang/zig-bootstrap.git bdfe02d4f6a93f216eaddfe4ef6c8825b3119f88)
Target: x86_64-unknown-macos-gnu
Thread model: posix
InstalledDir: /home/user
(in-process)
"/snap/zig/3096/zig" -cc1 -triple x86_64-unknown-macosx10.4.0-gnu -Wundef-prefix=TARGET_OS_ -Werror=undef-prefix -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -E -disable-free -disable-llvm-verifier -discard-value-names -main-file-name hello.m -mrelocation-model pic -pic-level 2 -mframe-pointer=all -fno-rounding-math -munwind-tables -faligned-alloc-unavailable -fcompatibility-qualified-id-block-type-checking -target-cpu core2 -debugger-tuning=lldb -v -resource-dir /snap/zig/lib/clang/11.0.1 -isysroot /home/user/Desktop/osxcross19/SDK/MacOSX10.15.sdk -internal-isystem /home/user/Desktop/osxcross19/SDK/MacOSX10.15.sdk/usr/local/include -internal-isystem /snap/zig/lib/clang/11.0.1/include -internal-externc-isystem /home/user/Desktop/osxcross19/SDK/MacOSX10.15.sdk/usr/include -fdebug-compilation-dir /home/user -ferror-limit 19 -fblocks -fblocks-runtime-optional -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fobjc-runtime=macosx-10.4.0 -fobjc-dispatch-method=non-legacy -fobjc-exceptions -fexceptions -fmax-type-align=16 -fcolor-diagnostics -o hello -x objective-c hello.m
clang -cc1 version 11.0.1 based upon LLVM 11.0.1 default target x86_64-linux-musl
ignoring nonexistent directory "/home/user/Desktop/osxcross19/SDK/MacOSX10.15.sdk/usr/local/include"
ignoring nonexistent directory "/snap/zig/lib/clang/11.0.1/include"
ignoring nonexistent directory "/home/user/Desktop/osxcross19/SDK/MacOSX10.15.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/home/user/Desktop/osxcross19/SDK/MacOSX10.15.sdk/usr/include
/home/user/Desktop/osxcross19/SDK/MacOSX10.15.sdk/System/Library/Frameworks (framework directory)
End of search list.
In file included from hello.m:1:
In file included from /home/user/Desktop/osxcross19/SDK/MacOSX10.15.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:6:
/home/user/Desktop/osxcross19/SDK/MacOSX10.15.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:17:10: fatal error: 'stdarg.h' file not found
#include <stdarg.h>
^~~~~~~~~~
1 error generated.
I'm under the impression stdarg.h should be provided by the compiler.
It's fine to expect just the low-level Objective-C runtime API-s like objc_msgSend. An idiomatic zig library can always be written atop this.
I know people have been able to link to libraries originally written in Objective-C, because it uses the C calling convention. And as you say, the runtimes (there is more than one to choose from) are just C libraries. Compile-time code can translate to the API from something more Ziggy. So the things that need to be built into the language for this are few, and most are already part of it, yes?
I don't know much about the guts of Obj-C (or Zig ...), so for my better understanding, what else would need to be part of Zig (the language, and the compiler) to make this work? It it as simple as Zig knowing how the files are organized inside a framework (which is, for other outsiders, a specific directory structure containing code), so it can find functions to call? Does the compiler have to cover Objective-C's (few) extensions to C syntax? [Clang already knows Obj-C.]
Incase this is useful for anyone: I'm actively working on ObjC runtime bindings atm. I currently have Class lookup and and message sending working which covers a lot of usecases on it's own. I'm in the process of adding support for declaring ObjC Classes. ~~I'm updating this Gist as I add features: https://gist.github.com/hazeycode/ec2a21d33706667d27a3bb9dd5d950a7~~
EDIT: outgrown the gist and moved to new repository: https://github.com/hazeycode/zig-objcrt
UPDATE: defining and registering classes with the runtime is now supported!
@mitchellh is also looking at this
@andrewrk
Are there any plans in zig for making it easier to consume Objective-C frameworks? This would enable iOS and mac development in a way that isn't possible without a lot of effort in languages such as rust.
Thinking aloud, It certainly seems that zig's approach of having clang parse C headers could be extended to Objective-C frameworks. Additionally, the Objective-C runtime would need to be wrapped, but that's a plain C library, so hopefully that's not too hard. There are some odd function signatures to deal with.
It's fine to expect just the low-level Objective-C runtime API-s like
objc_msgSend
. An idiomatic zig library can always be written atop this.In other words, this would eventually add to zig the features needed to be an "Objective-Zig".
I'd like to add that the Objective-C runtime is far more powerful than normally assumed. It has been described as "middleware with language features". This article on Software ICs is an interesting and exciting read. It takes only a small amount of effort for a language to support this runtime and in return it gets a wealth of capabilities. As an example, Xamarin added support for the runtime into .net and created one of the leading cross-platform app development tools, capable of producing entire iOS and Mac apps without a single line of swift or Objective-C. The runtime adds no overhead when not used and is basically a dynamic dispatch resolution system that provides binary-level glue across languages that support it.
Thoughts?