Zig build system | Hacker News Reader

Zig build system

en.liujiacai.net

185 pointsSerCe108 comments

The Zig build system is now able to run tasks in parallel. To avoid overloading the system (ie to prevent OOM) it asks you to define MaxRSS for each task, resulting in pretty sweet usage consumption: https://ibb.co/FW9kpxT

On a M1 Ultra studio (the same from my screenshot above) it takes me 6 mins to run the entire compiler test suite for arm64-linux (I do development in a Linux VM), which is pretty sweet.

Note that this is one stepping stone for getting good performance from Zig, but it's not yet incremental compilation with in-place binary patching [1]. That's still a work in progress.

[1] https://kristoff.it/blog/zig-new-relationship-llvm/

Just want to say your first link trigger fraud protection alert.

Is it possible to use zig without the zig build system, in order to slowly integrate a new language in an existing program?

For example, can I use the C backend to compile zig to C, and then use the system compiler as I would normally do with a meson cross file or CMake toolchain file?

If I understand your question it is:

Is it possible to write zig modules which would be liked to the bigger project otherwise written in C, C++ & c?

And moreover, to produce C "blobs" from zig sources which would be then part of the bigger project written in other languages?

I'd also like to know the answer to both!

> For example, can I use the C backend to compile zig to C, and then use the system compiler as I would normally do with a meson cross file or CMake toolchain file?

It's possible, but:

1. The C backend isn't 100% there yet. You won't be able to use all features and might run into bugs.

2. The generated code won't be very readable, it's arguably not too different from just using Zig-compiled object files directly in terms of "opaqueness" and legibility.

If neither of these are a big problem for you (both points are likely to improve with time), then yes, you could do that.

Readability is not an issue, as long as there are #line directives and symbol names are preserved so it is possible to use gdb.

The idea would be that if C files are reproducible across multiple environments (esp. 32 vs 64 bit) the end user would not need a zig toolchain.

To supply a data point: As of Zig 0.11.0-dev.2615+0733c8c5c, on an x86_64-linux host, the C backend is passing 1568 behavior tests compared to 1587 behavior tests passed by the LLVM backend on the same host. So, yes, it is not 100% there yet - it is 99% there :-)

Ah, good to know! My main sources were the release notes and occasionally your tweets (the account seems to have gotten suspended?), so my information was understandably a bit out of date. Glad to see progress being made though.

I feel like Zig can dominate the shellcode space, especially with pluggable allocators and minimalism. Is there any work towards outputting a naked payload for the lack of a better word? Given just the ISA, calling convention etc., producing something that starts from main() and does nothing but what is contained within main?

Totally, just use `zig cc` as an in-place replacement for clang and move forward from there as you feel comfrotable. I wrote a blog post about this approach: https://kristoff.it/blog/maintain-it-with-zig/

I am asking for the opposite, i.e. keep everything as is and only add 2-300 lines of zig.

In particular, I explicitly don't want to rewrite 15000 lines of build system code, so anything that uses build.zig is a nonstarter.

You can invoke Zig without build.zig:

    zig build-obj file.zig

And then include the object file along with your other sources. How you do this will of course depend on your build system.

If you want to see a fun example of this build system in action, have a look at my ffmpeg fork which has the build system ported to zig build:

https://github.com/andrewrk/ffmpeg

Particularly interesting is the use of nasm as a package dependency, which is executed to compile many assembly files into object files, which are then linked into the ffmpeg static library.

I'm using this package in a work-in-progress reboot of Groove Basin (a music player server) in Zig:

https://github.com/andrewrk/groovebasin/tree/zig-pkg

Point being that if you want to collaborate on the music player project, you don't need to screw around with a million system dependencies, it's just `zig build` and you're off to the races - no matter whether you are using Windows, macOS, or Linux.

The zig build system is under heavy construction during this release cycle of Zig. I recommend to check it out at the end of May when Zig 0.11.0 is released, and a few more issues will be smoothed over. Of course, if you want to get your hands dirty and help work on a bleeding-edge build system & package manager, come on over and give master branch a try.

First time I have seen the dotty zon file, it looks like zig anonymous struct syntax? If so, does that mean the structs/information in the zon file can be merged/included directly into the build.zig file where the dependencies are mentioned again? ie avoiding the zon file altogether? Maybe it is documented? but you are all working so fast I cant keep up :) I saw a http client/server push (btw nice!) that seemed to also include some new syntax that I wasnt familiar with; for(n..n2) etc. Anyway exciting times and great to see solid progress, well done.

I made a blog post about the new for loop syntax (spoilers: ranges are only one of the new features): https://kristoff.it/blog/zig-multi-sequence-for-loops/

libsodium is written in C and Assembly, but uses Zig as an alternative to autoconf/make/etc.

Builds are much faster than with make, and it makes it very easy to cross-compile to other platform, includes Windows, Linux with specific glibc versions, and WebAssembly.

In fact, it was the easiest to build Linux binaries for .NET, that have to support glibc back to version 2.17, but on a recent OS, with a recent compiler toolchain.

Can you write about the reasons for much faster builds, as far as you know?

Is it mainly due to the zig's caching of the build artifacts?

I'm not who you are replying to, but it's almost certainly due to autoconf &c. For many libraries on a machine with lots of cores, autoconf can take longer than the build, since autoconf isn't parallelized.

Also, IIRC, many smaller projects using autoconf have copied in a bunch of boilerplate feature tests that they don't need, like "is strncpy available" "is snprintf available" "does realloc NULL work". As you mention, each one of these tests generates and compiles a minimal C file, and not in parallel.

(And each test generates/defines a HAVE_SNPRINTF etc macro that your code can use to adapt based on available features. But if the project isn't as big as curl or git, it probably doesn't really adapt to all possible old and obscure systems anyway, so there's no point to 100s of such tests.)

Thanks, both are good general tips, but in this specific case

https://github.com/jedisct1/libsodium

I would guess that the author of the library has full control both over optimal parallelization of a build and minimal autoconf, but he can still observe a huge speedup, so I'd still like to read his answer.

This is not due to autoconf. It's faster than the `make` command, i.e. after autoconf has generated everything.

Building the tests, in particular is instant with zig, not with make.

It may still be autoconf, but not the configure phase, rather the complexity of the generated makefiles.

I've been confused by the statement that "Zig can compile C Code" for quite some time and reading a couple of blog posts hasn't made it much clearer.

Does the Zig Project include a full blown C Compiler? Is it the Zig Compiler with some sort of adaptation to compile C code? Or does it use something like Clang behind the curtains? (In this case it would be responsible for some other parts of the compilation process)

I believe the answer is two-fold:

1. It uses LLVM as the default backend, in which case that handles C as well

2. Optionally, and in the future by default, the Zig backend (a different one from the LLVM one) includes a C compiler (?)

Something like that. Its very powerful and it has the best C integration of any language in my experience (better than C++ since it effectively namespaces C headers).

Thanks for the answer but some things are still not entirely clear.

Who would be doing the parsing of C code for instance? Clang is also based LLVM but it is responsible for a load of C-specific stuff like parsing the language and feeding it into LLVM for instance.

I've got little experience with this stuff so I'm not sure if my questions even make that much sense.

(Edit: I believe ptato has answered my question above.)

You can invoke `zig cc` with the same flags that you would pass to `clang`. Zig cc takes your arguments, inspects them and applies some transformations and then Zig invokes its internal copy of clang with the resulting flags. One example of transformation is enabling ubsan when building in debug mode, another is `-target` which makes Zig add some sysroot flags to enable cross-compilation.

In this case all the file operations are handled by clang, Zig basically just sets up all the advanced flags for you when it makes sense to do so. One last example of CLI rewriting is related to the caching system: Zig cc knows how to cache a build by passing to clang the same kind of flags that cmake (or other build systems) would.

There's another C-related feature of Zig that works differently: `@cImport()`, which is a builtin that allows you to import C header files directly into a Zig script, in order to use from Zig all the types exposed by the header file. This one translates the C syntax in equivalent Zig syntax. I believe it uses clang's code to parse the C code into an AST, but then it's all Zig logic from there.

Lastly, we have a C frontend project going (arocc, linked by ptato) on that we plan to eventually upstream into Zig. This would be a replacement for clang and would work by parsing the C code and translating it into Zig IR, similarly to how the D programming language does it. The only limitation of this approach is that it would only support C, not C++, so we would either have to still keep clang around for C++, or ditch clang but then lose C++ compilation support. That said, even in the case where we keep clang around for C++ support, it would be worth having a custom C frontend for the Zig compiler in order to have more fine-grained control over the compilation process than what we can get from clang, plus the fact that it would make debug builds faster, since we could avoid invoking LLVM completely in that case (ie debug builds) even if you depend on C code.

How does this work on the assembly support side? I can see inline assembly, something called global assembly, but is Zig build also able to build standalone assembly main.asm type files?

From the `zig build-exe` help menu:

    Supported file types:
                      .zig    Zig source code
                        .o    ELF object file
                        .o    Mach-O (macOS) object file
                        .o    WebAssembly object file
                      .obj    COFF (Windows) object file
                      .lib    COFF (Windows) static library
                        .a    ELF static library
                        .a    Mach-O (macOS) static library
                        .a    WebAssembly static library
                       .so    ELF shared object (dynamic link)
                      .dll    Windows Dynamic Link Library
                    .dylib    Mach-O (macOS) dynamic library
                      .tbd    (macOS) text-based dylib definition
                        .s    Target-specific assembly source code
                        .S    Assembly with C preprocessor (requires LLVM extensions)
                        .c    C source code (requires LLVM extensions)
    .cxx .cc .C .cpp .stub    C++ source code (requires LLVM extensions)
                        .m    Objective-C source code (requires LLVM extensions)
                       .mm    Objective-C++ source code (requires LLVM extensions)
                       .bc    LLVM IR Module (requires LLVM extensions)
                       .cu    Cuda source code (requires LLVM extensions)

Ah! thanks, I'd been using 'zig --help build-obj' vs 'zig build-obj -h'.

And just to say the WebAssembly support is amazing, well done and thanks!

> in which case that handles C as well

And not just C, but also C++ and Objective-C - including all the hairy stuff to create macOS executables without the Apple toolchain.

Zig embeds clang to compile C code. This doesn't add a new dependency since Zig already depends on LLVM. If there is a future where the self-hosted Zig backend is good enough to not depend on LLVM anymore, there might be a reason to use a C compiler written in Zig (possibly https://github.com/Vexu/arocc)

It adds a new dependency - the c language frontend - aka clang - surely the zig compiler emits LLVM IR, not C code?

zig supports importing C headers via the special built-in `@cImport`. That feature requires a C language front end to operate. https://ziglang.org/documentation/0.10.1/#Import-from-C-Head...

Zig has a C backend that supports something like 99% of all Zig if I'm remembering the number correctly.

Zig has almost completely solved the bootstrap problem.

This isn't quite correct. Yes, it can output C code; however the result is not very readable at all, and fails the DFSG on generated code. It _is_ useful for compiling Zig code to targets which aren't supported by LLVM, however.

Do you have a reference for this? Does it use a C backend that is part of LLVM, or is it something Zig-specific? What are its limitations? Can it compile libraries to C, or only entire applications?

I have wanted Rust and Zig to support compile-to-C for a while, so this is exciting news for me.

One thing that would particularly interest me is if functions intended to be inlined could be emitted into .h files.

Also worth noting that Zig embeds C stdlib source code (musl if I'm not mistaken). That means it is easier to cross compile C projects using zig since you don't need to install a cross toolchain. This is why some golang/rust projects use Zig when they need to cross compile.

Others answered direct questions.

I'd like to add the link to the use examples demonstrating features of zig for c and c++ compilation available with the default zig installation which aren't directly available after installing clang:

https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

Previous discussions:

https://news.ycombinator.com/item?id=22679138

https://news.ycombinator.com/item?id=27872596

Zig actually transpiles the C code into Zig code, then compiles that

No, that is not true. `zig cc` uses libclang to compile it in the same way that clang would.

Sorry, I wasn’t specific. I was talking about how cImport works in Zig. I didn’t know `zig cc` worked differently.

“ Zig’s @cImport builtin is unique in that it takes in an expression, which can only take in @cInclude, @cDefine, and @cUndef. This works similarly to translate-c, translating C code to Zig under the hood.” https://ziglearn.org/chapter-4/

Glad to see a Zig Build for Raylib. I am using Zig to compile most of my C stuff now as I learn Zig. This makes Zig much more attractive to anyone considering learning it. It's easier than Make and CMake for me.

There's also a project that generates automatic bindings for raylib:

https://github.com/Not-Nik/raylib-zig

Interesting. I wonder if it allows adding dependencies at runtime? (As explained in eg http://simonmar.github.io/bib/papers/shake.pdf )

You mean when the build runs?

Since it’s zig code, I think you would have that flexibility.

Yes, dependencies you only discover as you run the build.

Can you debug zig in any MS/jetbrains IDEs? I type in nvim but debug in whatever has the best experience. I think I asked this question like 2 years ago and was told you can write tests, use lsp server or look at assembly.. has situation improved?

The best debugging experience imo is using gdb and rr within nvim. Works for zig, c, rust, etc. with minimal configuration in nvim. The less I leave vim the more productive I can be. Same thing probably goes for emacs although I will never admit it.

I’d love if you could elaborate on your setup. Are you using something like nvim-dap from within neovim or something else? I’m still trying to improve my debug experience in neovim.

Would also love to hear more. I have nvim-dap set up for Go and for C and it is an OK experience but I would not call it great. This is something on my Neovim todo list.. improving my debugging experience.

Not so sure about any real IDEs, lldb has worked fine for the (fairly small) zig programs I've worked on and the "CodeLLDB" vscode extension worked. Of course with the move from LLVM i assume lldb will stop working, and vscode may not be a good enough debugging experience.

AFAIK the LLVM backend won't go away in the standard Zig distribution even with the new non-LLVM backend.

But even without LLVM backend I would expect that Zig will be able to produce DWARF debug information.

I've been able to debug Zig in Windows by simply opening the .exe file with Visual Studio. I didn't explore much what can be done in it but it is possible.

At least DWARF is supported (e.g. any gdb or lldb frontend works, e.g. what various VSCode extensions like CodeLLDB offer). Not sure about PDB support on Windows actually.

This also means you can transparently debug-step from Zig into C code and back, which is kinda expected but it never gets old for me :)

I use VS Code on Linux to debug Zig. Haven't tried the others you mentioned, but it just emits standard DWARF symbols, so I'm guessing if you can debug C/C++ you could probably also do Zig with minimal changes? I just use the lldb VS code plugin[0], which works out of the box for me with no issues.

https://github.com/vadimcn/codelldb

I take it so that zig build system is Turing complete, isn't it? There is a reason why, for example, meson build system DSL is made to be non-Turing complete. It makes reasoning much simpler.

When it comes to reasoning ability, Turing-completeness is a red herring. Turing-completeness falls beyond the reasoning ability of something that has unbounded computational power and unbounded patience, but because people only have access to bounded computational power and have bounded patience, their limit of feasible reasoning are well below Turing-completeness.

A language with nothing but boolean variables and functions with no recursion, or a language with nothing but boolean variables and loops of up to a depth of 2 can already encode TQBF [1], which makes reasoning about it intractable (it's PSPACE-complete). Because most build systems fall within that category they might as well be Turing complete.

[1]: https://en.wikipedia.org/wiki/True_quantified_Boolean_formul...

Yes, it makes reasoning simpler.

But then some things become impossible to do.

I'm creating a different build system (not Zig's), and I'm taking a different approach. Instead of a non-Turing-complete language, I've made one that is as powerful as possible. However, it will allow users to restrict the language so that they will only use subsets, and those subsets will not necessarily be Turing-complete.

In this way, it has the power to do anything, but the ability to restrict that power for ease-of-use.

IME you really need a programming language to describe a build, even when it is desired that the result looks 'mostly declarative' in the end.

E.g. not sure how Meson handles this, but when I have a project with dozens of similar build targets and platform specific compile options, I really want to do the build description in a loop instead of a data tree.

(for example: https://github.com/floooh/sokol-zig/blob/3f978e58712f9eb029b...)

PS: apparently Meson build scripts can also have variables, conditions and loops, which I guess makes the difference to an actually Turing complete build system rather esoterical?

https://mesonbuild.com/Syntax.html#logical-operations

A proper build system is so much more than just describing build targets and their dependencies, you also want to generate source code, copy and process data files, communicate with REST services etc... The more this happens in a 'real' programming language the better.

I fell in love with the ninja build system recently. It's machine language for build systems, and I can write my own scripts to generate the ninja build file, rather than introducing any new language from someone else just for build descriptions.

Is ninja not expressive enough for your needs?

Meson has the ability to generate code and process data files. Why do you need to communicate with REST? Meson support that however by allowing you to break out using the `run_command()` function.

Uploading build output somewhere for instance. However this may overlap with CI tasks (but there, usually YAML is used to run shell commands, which is also a bit of a crutch).

That is a task for CI, not for a build system. A build system should ideally be able to run in a container that has no network at all.

That's just your opinion though ;) Why should the process of producing a build artifact be different from putting the artifact into the right place? E.g. Makefiles usually have a 'make install' step which isn't all that different from uploading the build result somewhere, and make definitely counts as a build system.

I'm holding my breath. The first day out I ran into a link problem. Zig linked statically not dynamically as instructed and while the task was produced, it didn't work anyway. That's not gonna be fixed I believe until 0.11.0. now to give credit where due, the head guy (Andrew if I recall) had already found this issue or a good part of it.

zig looks like a 'better C', is there a list of something it does better than C(e.g. integer promotion,UB,etc), so that I should embrace it quickly and start to use it in my embedded projects? would like to see a comparison table between zig vs c (or even c++)

I did a bit of Zig exploration a few months ago, here's a few things that caught my attention:

- You don't have implicit allocations when using Zig stdlib. For example, when you instantiate an ArrayList or HashMap, you need to pass in an allocator, so you have full control over how memory is managed. So, even though you have higher level data structures, you still have a lot of low level control.

- Very good error handling. IMO better than Rust and Golang, while still being very explicit about what is happening

- "Uncolored" async functions, meaning there's no special syntax for declaring functions that can be paused/resumed. If I understood correctly (didn't try it a lot), you can turn any program into "async" by changing how I/O is handled globally. More details here: https://kristoff.it/blog/zig-colorblind-async-await/

Here's a nice overview of Zig that should make even more sense if you know C: https://ziglang.org/learn/overview/

As far as language features go: extensive comptime support, error handling and optionals integrated into the language, a new (to me at least) twist on generics, type reflection, and a couple of smaller 'convenience features' like type inference, if and switch being expressions, etc...

Reading this from top to bottom gives a pretty good overview:

https://ziglang.org/documentation/master/

I would recommend this talk by the creator of Zig: https://www.youtube.com/watch?v=Gv2I7qTux7g&t=3021s

He gives some examples of C vs Zig and what they tried to improve.

Zig things that I miss when I have to go back to C:

- All integer operations trap on overflow in safe build modes; with explicit operators for saturating or wrapping arithmetic

- No implicit integer promotion unless the destination type can represent all values of the source type (so no implicit signed/unsigned conversions unless they're statically guaranteed to be safe - e.g. a u8 can coerce to an i32 but not to an i8)

- Arbitrary bit-size integers (C23 will have this)

- Enums that are actually useful and fun, vs the complete waste of time that C's enums are (Enum values are namespaced, you can't directly use their values as integers, you can control the underlying representation if you want, etc)

- Built-in support for tagged unions, also known as sum types (bare union + a tag indicating which field is active)

- Safe unions in safe build modes (compiler inserts a hidden tag to track which field is active)

- A standard library that's actually useful (it's small compared to some other languages, and not well-documented yet, but it's not littered with landmines the way C's is)

- A modern import system instead of preprocessor-style copy/pasting text

- Compile-time programming in Zig, instead of preprocessor macros

- Arrays are an actual type, instead of decaying to pointers

- Much better support for pointers (pointer + length AKA slices are the primary way to deal with multiple items whose length can vary at runtime; also single-item pointers and multi-item pointers are different types, so you can't accidentally index into a single-item pointer or attempt to dereference a multi-item pointer without providing an index)

- Errors must be handled, with convenient syntax for passing the error up the stack + inferred error sets so that you don't have to explicitly annotate the set of possible errors for most functions

- Nulls encoded in the type system so that they must be explicitly handled.

- test blocks for writing tests inline and running them with `zig test`

Why is Zigs syntax so ... foreign?

To whom?

To me, for example.

> .{}

Is C foreign to you? Zig syntax is nearly identical to how C initializes structs.

For the example you cited (anonymous struct literals), there are two parts to it:

1) It omits the constructor name. My uneducated guess is that "modern" languages try to avoid the Java-style pattern of repeating a type/constructor many times in a single line (e.g., "Point pt = new Point(0, 0)") when it can infer things to help the developer.

2) It starts with a dot, while C++'s compound literals (for example) don't. The pros and cons of this are discussed in https://github.com/ziglang/zig/issues/5039.

That's the same as using `{}` in C to initialize a struct. The dot only makes more clear that it's a struct literal and not a scope.

The language cetainly seems to like using that 'dot' operator:

    const exe = b.addExecutable(.{
        .name = "demo",
        .root_source_file = .{ .path = "src/main.zig" },
        .target = target,
        .optimize = optimize,
    });

It's not invented by zig: https://en.cppreference.com/w/c/language/struct_initializati...

Although more widely used.

The word for German in many Slavic regions is something like Njemacki (and similar). Loosely translated it means "Those who cannot speak".

Of course, Germans can speak and languages of German descent are just as rich, precise and expressive as any other. But the term Njemacki probably stuck around out of an initial ignorance about a foreign culture in earlier times and lack of general education.

>initial ignorance about a foreign culture in earlier times and lack of general education

I upvoted your comment because I agree with it in the context of the parent, but this ending explanation is frankly ridiculous. It sounds like early Slavs had no idea that Germanic tribes had their own languages which is just plain impossible. Proto-Slavic němъ meant also unintelligible/hard to understand. So contrary to popular opinion those Slavic words for Germans doesn't (and didn't) mean mute (or "cannot speak"), it's just that in modern Sl. languages words stemming from němъ evolved to indicate mostly muteness.

Thank you for the clarification. I tried to exaggerate my point, but what you say is obviously true and much more nuanced.

In fact it's so easy to forget or ignore that we humans were just as smart and creative thousands of years ago as we are today.

But it's interesting and funny to think that our ancestors called each other mute, or rather unintelligible, because they didn't understand what the other one was saying. I find it endearing how we often stumble over our own limitations and quirks, so much that it is often ingrained in language and culture.

Good reply. Thank you!

> out of an initial ignorance about a foreign culture in earlier times and lack of general education.

Like how the Ancient Greek lacked education (Barbarians). ;)

Only for the first half an hour. Coming from C I found the Zig syntax very straightforward after writing a couple of hundred lines of code.

But why?

Someone needs to make a competing build system called Zag, just so I can eventually make the joke "we Zigged where we should have Zagged" after Zig has some major issue in our build env.

I want Zag to be what Python is to C.

That's another fun option and opens up a whole new branch of fun like ZigZag a compatibility layer for running Zig builds in Zag.

Had the same thought. The naming synergy is perfect.

Ringworld reference?

Once Zig is done, may be Zag could be a superset of Zig where it focuses on application and slightly higher level development. Think C++, Swift and Java.

Looks like people behind Zig decided to drop support for macOS Catalina, OS released just 3 years ago. So it is not possible to compile Zig for it. It is ridiculous. https://github.com/ziglang/zig/issues/13313#issuecomment-129...

Maybe they'd accept a PR if you volunteer to maintain that work?

As "ridiculous" as it might be, we're a small non-profit and have to prioritize where to allocate our resources as we develop Zig. When it comes to macOS, we follow the same policy as Apple: support the latest 3 versions of it.

Maybe once Zig is fully developed we'll focus our effort on more retrocompatibility.

If you want to help us get there faster, consider donating to the Zig software foundation, as we're looking to hire more developers to work full time on Zig (we're 4 full-time people right now).

https://ziglang.org/zsf/

No, I will not donate, because I think that my money will be spend on unnecessary effort of removing already supported targets, instead of meaningful tasks, like writing simple check in CMake to indicate that given OS is not supported instead of failing with vague error message on link time step.

Honestly that just sounds like "I want things for free, but I'm not willing to give back anything in return".

Even though as you say atm. Apple does not support <=10.15. Latest Xcode 14.3 still supports building applications that target macOS 10.13.[1]

So that is not an excuse to drop support for 10.15.

[1] https://developer.apple.com/support/xcode/

Apparently Apple doesn't support their own OS released just 3 years ago? Why would other people support it?

You can't even run the current Xcode version on the previous macOS version, which is much more ridiculous, but that's the Apple software development ecosystem for you ;)

Latest Xcode 14.3 supports building applications that target macOS 10.13.

https://developer.apple.com/support/xcode/

While Zig is not even 10.15.

  andrewrk commented Feb 17, 2023 •
  macOS 10 is no longer supported by Apple, and therefore also no longer supported by Zig. You have to use one of the latest 3 versions or else your system is not being patched for security vulnerabilities, and likewise zig does not provide support for cross compiling to anything less than the latest 3 versions.
  https://ziglang.org/download/0.10.0/release-notes.html#macOS

https://github.com/ziglang/zig/issues/14651#issuecomment-143...

Yes you can build targets for older macOS version, but can't do so on older macOS versions (unless you dig up a matching Xcode version).

But for a pre-1.0 language in development the decision is completely justified IMHO. Catalina is quite ancient by macOS standards.

> Latest Xcode 14.3 supports building applications that target macOS 10.13.

That is not what the parent said

Supported systems are listed here:

https://ziglang.org/download/0.10.0/release-notes.html#Suppo...

I also had this issue with a non-updatable MBP, but linux support is good, and I am looking forward to trying Zig out with Risc-V when I can get my hands on some hardware that hopefully wont expire as fast.

Yes, and dropping Catalina means Zig disregards a lot of not really that old and still powerful Apple hardware, except what on this list:

  iMac (Mid 2014 or later)
  iMac Pro
  MacBook (Early 2015 or later)
  MacBook Air (Mid 2013 or later)
  MacBook Pro (Late 2013 or later)
  Mac Mini (Late 2014 or later)
  Mac Pro (Late 2013 or later)

https://en.wikipedia.org/wiki/MacOS_Big_Sur

And by similarity of supporting last 3 macOS release, this will grow to hardware of ~2016 if they drop support of Big Sur next.

You don't have to use an unsupported, no longer updated, OS on any Apple hardware made in the last 20 years. Just upgrade to GNU/Linux.

Especially Void, the best distribution ever!

Zig will eventually support compiling to C, so any platform not directly supported that has a working C compiler will work.

We already support that. That's (part of) how we bootstrap the compiler :^)

Reply on news.ycombinator.com