[HN Gopher] Zig build system
___________________________________________________________________
Zig build system
Author : SerCe
Score : 170 points
Date : 2023-04-14 08:05 UTC (14 hours ago)
(HTM) web link (en.liujiacai.net)
(TXT) w3m dump (en.liujiacai.net)
| eggy wrote:
| 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.
| hiccuphippo wrote:
| There's also a project that generates automatic bindings for
| raylib:
|
| https://github.com/Not-Nik/raylib-zig
| quirino wrote:
| 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)
| acqq wrote:
| 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
| 2fast4you wrote:
| Zig actually transpiles the C code into Zig code, then compiles
| that
| wyldfire wrote:
| No, that is not true. `zig cc` uses libclang to compile it in
| the same way that clang would.
| 2fast4you wrote:
| 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/
| lionkor wrote:
| 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).
| flohofwoe wrote:
| > 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.
| quirino wrote:
| 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.)
| kristoff_it wrote:
| 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.
| whitehexagon wrote:
| 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?
| kristoff_it wrote:
| 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)
| whitehexagon wrote:
| 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!
| ptato wrote:
| 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)
| richardwhiuk wrote:
| It adds a new dependency - the c language frontend - aka
| clang - surely the zig compiler emits LLVM IR, not C code?
| daurnimator wrote:
| 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...
| [deleted]
| tristan957 wrote:
| 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.
| trashburger wrote:
| 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.
| haberman wrote:
| 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.
| tarruda wrote:
| 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.
| jedisct1 wrote:
| 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.
| acqq wrote:
| 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?
| aidenn0 wrote:
| 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.
| jedisct1 wrote:
| 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.
| ploxiln wrote:
| 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.)
| acqq wrote:
| 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.
| 64bittechie wrote:
| [dead]
| Alifatisk wrote:
| Why is Zigs syntax so ... foreign?
| flohofwoe wrote:
| 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.
| dgb23 wrote:
| 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.
| avgcorrection wrote:
| > 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). ;)
| brokenkebaby wrote:
| >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 nem' 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 nem' evolved to indicate mostly muteness.
| dgb23 wrote:
| 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.
| brokenkebaby wrote:
| Good reply. Thank you!
| mauricioc wrote:
| To whom?
| Alifatisk wrote:
| To me, for example.
|
| > .{}
| brabel wrote:
| Is C foreign to you? Zig syntax is nearly identical to how
| C initializes structs.
| mauricioc wrote:
| 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.
| jussij wrote:
| 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, });
| kristoff_it wrote:
| 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.
| [deleted]
| fancl20 wrote:
| It's not invented by zig: https://en.cppreference.com/w/c/l
| anguage/struct_initializati...
|
| Although more widely used.
| malkia wrote:
| But why?
| diimdeep wrote:
| 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...
| kristoff_it wrote:
| 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/
| diimdeep wrote:
| 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/
| diimdeep wrote:
| 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.
| YorickPeterse wrote:
| Honestly that just sounds like "I want things for free, but
| I'm not willing to give back anything in return".
| hiccuphippo wrote:
| Apparently Apple doesn't support their own OS released just 3
| years ago? Why would other people support it?
| whitehexagon wrote:
| 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.
| diimdeep wrote:
| 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.
| lvass wrote:
| 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.
| Conscat wrote:
| Especially Void, the best distribution ever!
| hiccuphippo wrote:
| Zig will eventually support compiling to C, so any platform
| not directly supported that has a working C compiler will
| work.
| kristoff_it wrote:
| We already support that. That's (part of) how we
| bootstrap the compiler :^)
| bbkane wrote:
| Maybe they'd accept a PR if you volunteer to maintain that
| work?
| flohofwoe wrote:
| 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 ;)
| diimdeep wrote:
| 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.
| ..
| flohofwoe wrote:
| 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.
| YuukiRey wrote:
| > Latest Xcode 14.3 supports building applications that
| target macOS 10.13.
|
| That is not what the parent said
| kristoff_it wrote:
| 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/
| bonzini wrote:
| 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?
| acqq wrote:
| 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!
| e4m2 wrote:
| > 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.
| AndyKelley wrote:
| 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 :-)
| e4m2 wrote:
| 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.
| bonzini wrote:
| 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.
| kristoff_it wrote:
| 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/
| bonzini wrote:
| 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.
| gpanders wrote:
| 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.
| ksec wrote:
| Just want to say your first link trigger fraud protection
| alert.
| synergy20 wrote:
| 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++)
| fileeditview wrote:
| 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.
| tarruda wrote:
| 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/
| kristoff_it wrote:
| Here's a nice overview of Zig that should make even more sense
| if you know C: https://ziglang.org/learn/overview/
| defen wrote:
| 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`
| flohofwoe wrote:
| 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/
| adelm wrote:
| 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.
| flohofwoe wrote:
| 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.
| Syzygies wrote:
| 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?
| tristan957 wrote:
| 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.
| flohofwoe wrote:
| 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).
| bonzini wrote:
| 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.
| pron wrote:
| 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...
| gavinhoward wrote:
| 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.
| eru wrote:
| Interesting. I wonder if it allows adding dependencies at
| runtime? (As explained in eg
| http://simonmar.github.io/bib/papers/shake.pdf )
| jmull wrote:
| You mean when the build runs?
|
| Since it's zig code, I think you would have that flexibility.
| eru wrote:
| Yes, dependencies you only discover as you run the build.
| Hnus wrote:
| 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?
| flohofwoe wrote:
| 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 :)
| jcalabro wrote:
| 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
| duckqlz wrote:
| 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.
| immrammc wrote:
| 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.
| fileeditview wrote:
| 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.
| sciolistse wrote:
| 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.
| flohofwoe wrote:
| 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.
| hiccuphippo wrote:
| 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.
| AndyKelley wrote:
| 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.
| whitehexagon wrote:
| 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.
| kristoff_it wrote:
| 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/
| [deleted]
| rtkwe wrote:
| 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.
| klyrs wrote:
| I want Zag to be what Python is to C.
| rtkwe wrote:
| 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.
| slowking2 wrote:
| Had the same thought. The naming synergy is perfect.
| winrid wrote:
| Ringworld reference?
___________________________________________________________________
(page generated 2023-04-14 23:01 UTC)