Proper way to reuse c headers from the exposed lua library

[bfredl]

In addition to using the @import("ziglua") module from zig code, I need to compile additional C extensions which depend on the headers for the correct lua version as exposed by ziglua.

After some trial and error I found this to work:

    my_module.addImport("ziglua", ziglua.module("ziglua"));
    // addImport already links by itself. but we need headers as well..
    my_module.linkLibrary(ziglua.artifact("lua"));

This feels a bit hacky as it relies on the artifact name "lua" which might be seen as internal to ziglua (not part of the exported module), and also, as addImport by itself is enough to add the .o files for the lua library, linkLibrary would add the same objects a second time?
This should "safely" be handled gracefully by most linkers, but it would be best to avoid this if possible.

Any thoughts about what the proper way would be?

[natecraddock]

Hey @bfredl!

This is a use case I'm working on right now. Currently your approach is what I'm planning to do.

Just a few months ago actually, using ziglua.module("ziglua") only gave you the Zig module. You actually did need to use ziglua.artifact("lua") to link the lua library. Only recently did I link lua to the zig module by default.

I actually have a draft blog post (waiting for Zig 0.12.0 to stabilize the APIs) that shows how to compile LPeg linked against Ziglua in a project: https://bc4b5350.nathancraddock.pages.dev/blog/ziglua-package/#compiling-lpeg

Am I understanding your question correctly?

[bfredl]

Yes, that's exactly what I want. Including lpeg specifically, I discovered and had to work around the zig fetch bug yesterday myself 😅 .

[natecraddock]

Great! I'll keep this issue open for a bit. You raised some questions about linkers and I want to make sure that this approach is correct. Once I have confirmed that, and have this process documented I'll close it.

[bfredl]

Thanks. Just one more piece of information in case if it useful for anyone:

I also needed to get the lua include path as a LazyPath as well (this is workaround to an unrelated limitation in std.Build but anyway), which you can do using ziglua.artifact("lua").getEmittedIncludeTree() .