#How to add a zig package without compilation?

1 messages · Page 1 of 1 (latest)

mossy flame
#

I'd like to create a dependency for another package to depend on but the current package only has a .so and a .h file, is there a good way to write a build.zig that would only "copy" over the files instead of linking?

limber apex
#

why would you want to copy over a linked library?

mossy flame
#

So I can have another package depend on them. These linked library is from someone else

#

So as they release new versions, I can decide whether to add which version

#

for example, my current code depends on 0.8.1 of their library and say they release 0.9, mine may or may not change so I'd like to list them as a dependency but they are not a zig project

limber apex
#

alright, so this isn't interacting with the package manager then, aye?

mossy flame
#

id like to list it as a package manager dependency

#

So I have package C that depends on B which depends on A. A is not written by me, B is the zig interface of A, C is the program that depends on B

limber apex
#

alright, how does B depend on A?

#

is that the issue?

#

if yes, there's currently not a way to depend on projects which don't have a build.zig

mossy flame
#

B is a think Zig "fascade" for A to make C only care about Zig code not C++ code

#

Can I just use Build.installFile to install the header file?

limber apex
#

the current way it's usually accomplished is to fork A and add a build.zig to it that makes the relevant artifacts and stuff available

mossy flame
#

It's pretty convoluted to make the c++ code to build using Zig. I found it much easier to just use the .so

#

When they release the library, it only has lib.so, lib.h, and lib.hpp

#

and I found that I just need to use the lib.so and lib.h to make it work hence the question

#

I found that I can use b.installBinFile to "install" the .so file

limber apex
mossy flame
#

in B, I think I can make it work, right now I'm stuck on A

#

my current project has A/B/C all in one project so I'm working on splitting into A/B/C

limber apex
#

well, the usual way it works to make non-build.zig projects work with the package manager is to fork them and add a build.zig in your fork

mossy flame
#

got it, i think i can probably use b.installFile

#

do you know what does Build.addInstallHeaderFile do?

#

it returns a Build.Step.InstallFile, I'm not sure what do I do with it

limber apex
#

I'm not 100% sure

mossy flame
#

ok thanks

limber apex
#

I think there's missing infrastructure

#

right now, you can do b.dependency().module() and b.dependency().artifact(), allowing you to expose *Step.Compiles and *Modules, but there's no way to get a *Step.Install

#

but given that those installation functions exist, I can only imagine it may eventually become possible to expose those types of steps

mossy flame
#

Got it thank you.

#

I think i got a build.zig that just "copies" over the files

#

let me see how to make B work with such an A

mossy flame
#

@limber apex do you know what artifact means in the Zig sense? I kept on getting unable to find artifact "lib" and I'm trying to figure out what it means so I can see whether ti should be called lib or something else

limber apex
#

artifact basically just refers to Build.Step.Compiles

#

what function issues that error?

#

b.dependency().artifact("lib")?

#

the way it works is, the dependency has to have something like

const foo = b.add<SharedLibrary|StaticLibrary|Executable|Test>(.{
    .name = <artifact-name>,
    // -- snip --
});
#

and then do b.addInstallArtifact(foo);

#

this makes the artifact available to consumer's build.zig, via b.dependency(...).artifact(<artifact-name>)

mossy flame
#

ah, so I don't have them as artifacts, got it...

#

for A, my build.zig is ```
pub fn build(b: *std.Build) void {
b.installFile("include/duckdb.h", "include/duckdb.h");
b.installLibFile("lib/libduckdb.so", "libduckdb.so");
}

#

How would I refer to them in B?

limber apex
#

well, that's kind of the thing, I'm not aware of a way to make that available as an artifact

mossy flame
#

is it possible to make dependency "install" into zig-out first?

limber apex
#

the thing is, the zig-out directory isn't something that's usually used as a place to put things that are consumed by user libraries

#

normally artifacts and modules exist kind of in the "abstract", where if they're needed they're built and cached in zig-cache - and then if you want to install them, they're copied from there into zig-out, or whatever install prefix you dictate

#

give me a second

#

I'm going to look at something

#

yeah, really not 100% sure

#

I'm not sure if there's an issue open for this use case

#

if you have time, look around on the issue tracker, and see if there is

#

if there isn't, I suggest opening one

#

as this certainly seems like a use case that should be tracked and supported

mossy flame
#

got it thank you

#

sorry had a visitor in the office. had to open door and greet the guest

mossy flame
mossy flame
#

I actually make it work with a super HACK, use libA.so as if it's a header file, LOL