Hacker News Reader

Comment by AndyKelley | Hacker News Reader

Indeed, the Zig build system includes a package manager. Fetching, configuration, compilation, and installation are all 1 command:

    zig build

Furthermore, C and C++ code can participate in the Zig package ecosystem. For example, here is ffmpeg packaged for consumption by a Zig project:

https://github.com/andrewrk/ffmpeg

Why not use a system package? Well, because the user's system might not have such a package. They might be on Windows, for example. Or their package might be out of date. [Or the system might have chosen sides in a nasty fork war](http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html).

So, while system packages are nice for end users, they might not always satisfy the needs of upstream application developers.

View on HN

I wish Nix grew into this niche. It's fine now if users want to install a system daemon or deal with multi-user mode, but it'd be neat to have a polyglot package installer that you can run from the project directory, like you can do with Gradle (about the only positive thing I have to say about Gradle).

When will the package manager support binary libraries?

There is a world in the C and C++ commercial ecosystems that will never adopt tooling that doesn't support shipping some form of binary libraries.

I haven't tried it yet, but the Zig package manager should be flexible enough to deal with binary blobs? After all it's just pulling in an external directory and runs its build.zig (which then can make available precompiled libraries to the rest of the build process).

I am more thinking in the lines of Conan, vcpkg, NuGet, npm, Maven, Gradle, and system packages (with pkg-config), it is more than just a binary blob.

I remember reading somewhere that there was no plan for binary packages in Zig, given its FOSS point of view.

Yeah I guess you'd need to wrap "binary packages" into a library with C API (even if the implementation is written in Zig).

Such binaries will not be able to use anything but the special C-compatible types and calls, which is quite the limitation. Image if C++ static libraries could only use C compatible POD structs and none of the C++ parameter types for example.

> Image if C++ static libraries could only use C compatible POD structs and none of the C++ parameter types for example.

That's the only way to expose a C++ library to other languages though, or even make a DLL written for one C++ compiler consumable by a program written with another C++ compiler.

It's a limitation for sure, but definitely not a show stopper.

It isn't the only way, COM based APIs and similar approaches in Apple and Google platforms, allow for a more rich ABI without being constrained to C.

As far as I'm aware, COM based APIs *are* C-APIs, just with a couple of additional conventions for lifetime management via refcounting, versioning interfaces and wrapping C++ classes into structs with function pointer jump tables ;)

From that point of view they are Assembly APIs as well, after all C API is just a convention of registers being used and call frames.

They are just C-APIs which have a V-table, and Odin added a feature specifically to make dealing with them easier in the language too.

e.g. https://pkg.odin-lang.org/vendor/directx/d3d12/#ICommandQueu...

* command_queue^.id3d12commandqueue_vtable^.BeginEvent(command_queue, MetaData, pData, Size)

* command_queue.id3d12commandqueue_vtable.BeginEvent(command_queue, MetaData, pData, Size) // no need for the explicit dereferencing with ^

* command_queue.BeginEvent(command_queue, MetaData, pData, Size) // the vtable has `using` on it

* command_queue->BeginEvent(MetaData, pData, Size) // the -> operator will pass the value into the first argument

The `->` operator was added specifically for COM API stuff, and has been useful for the Objective-C stuff too.

Reply on news.ycombinator.com