Re: Strategy for Zig packages

[Mája Tomášek]

<mcsinyx@disroot.org> writes:

> a few options:
>
> 1. Wait until Zig reaches 1.0; it's too soon to decide now.
> 2. Work with Zig maintainers for a standard way to install
>    Zig libraries as source code.  It could be something like
>    ZIG_PKGS where package name is at $ZIG_PKGS/$name.zig,
>    or a file containing all the mappings.
> 3. Wrap the zig command and feed it declared dependency information
>    while waiting for standardization.

Hi,

iirc zig does support the shared library model,
but it by default links all objects statically.

I have been thinking about zig packages recently. How could guix say
this is the way to create packages for guix.

My idea that came to me, would be to support guix packages inside vendor
repository that could be exported as rpms/debs etc. etc. And all build
actions made by the mantainers.

But I understand it wouldn't be popular, locking an independent language
into the guix ecosystem.

More realistic (imo) is that zig should be encouraged to build
dynamically linked packages, not static ones, and allow the ability
(with their future package manager) for the distribution to distribute
it's libraries C-style. If there's a newer version required, it should
be up to the distribution mantainers to fix that.

With hope, that I haven't spattered utter nonsense and with love,
Maya

PS. I apologize for sending you the email twice McSinyx, I forgot to add
the mailing list in the copy.