Re: Strategy for Zig packages

[mcsinyx]

On Tue Aug 2, 2022 at 11:09 AM +0200, Maxime Devos wrote:
> On 02-08-2022 07:21, mcsinyx@disroot.org wrote:
> > On Mon Aug 1, 2022 at 10:43 PM +0200, Mája Tomášek wrote:
> > > 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.
> >
> > Technically this is not always possible since Zig relies
> > on compile-time execution for generic.
>
> Rust has generics (and macros (*)) and its compiler does
> static compilation, so I don't see why it would be impossible
> for Zig to do static libraries.
>
> (*) Including macros that can run arbitrary Rust code, see
> <https://doc.rust-lang.org/book/ch19-06-macros.html#declarative-macros-with-macro_rules-for-general-metaprogramming>,
> so there you have compile-time execution too!

FWIW I was commenting on the impossibility
of dynamically linking Zig libraries that uses comptime.

On Tue Aug 2, 2022 at 11:09 AM +0200, Maxime Devos wrote:
> I don't think this is a problem, as Guile has macros (*) yet
> it supports compilation (and shared libraries -- .go files
> are ELF shared libraries) -- macros are, in a sense,
> merely procedures that transform syntax into syntax,
> which can be compiled, and generics could be considered
> a special case of macros.
>
> (Shared libraries might be harder, but you could just monomorphise
> generics in the 'user' of the shared library, so shared libraries
> appear technically possible to me as well.)

Compile-time execution must be done at, well, compilation time,
thus macros in shared objects are just glorified embedded
source code that are not used at runtime.

That being said, there may be a Zig ABI in the future, with the cost
of missing certain features (like comptime) and optimizations:
https://github.com/ziglang/zig/issues/3786

On Tue Aug 2, 2022 at 11:11 AM +0200, Maxime Devos wrote:
> On 02-08-2022 07:21, mcsinyx@disroot.org wrote:
> > Zig source files could be handled in the same manner as C headers
> > however, and be used as native inputs, so downstream can still
> > update a library for all dependees at once.
>
> Going for native-inputs and not non-native sounds incorrect
> when cross-compiling.  We might need to substitute* a "executable"
> -> "/gnu/store/.../bin/executable", and the latter file name
> is architecture-dependent.  (This holds generally, including
> for C headers).

Thanks, coming from Nix I forgot that Guix does not make use of PATH.