[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strategy for Zig packages

From: Mája Tomášek
Subject: Re: Strategy for Zig packages
Date: Mon, 01 Aug 2022 22:43:58 +0200

<> 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.


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,

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]