Issue with system_lua option regarding header location

If you set system_lua to true, you may be given an error that it cannot find the Lua headers defined in build/include/*.h, because most distributions/operating systems will put the header files inside a subdirectory, e.g. /usr/include/luajit-2.1.

To fix this, I tried adding the LuaJIT include path using ziglua's additional_system_headers option, but that gave me a quite strange error:

error: warning: add "/usr/include/luajit-2.1" to header searchlist '-isystem' conflicts with '-I'

The fix for this is to add it as a regular include path with addIncludePath() instead of addSystemIncludePath(), but that may break other usecases (e.g. the one mentioned in the comment right above that call in the code).

So personally, I see two (good) options here:

Adding an additional_headers option, in the same vein as additional_system_headers;
Letting system_lua take a ?LazyPath type, where null means compiling the selected Lua version, and any LazyPath means adding the given path as an include path for translate-c.

The whole "system lua" feature feels like a messy hack to me... I wish it were easier to use. And I feel like these Zig options should somehow be useful. Yet every time I try (it has been a while) I can't get it to work in a cleaner way.

System Integration Options:
  --search-prefix [path]       Add a path to look for binaries, libraries, headers
  --sysroot [path]             Set the system root directory (usually /)

  -fsys=[name]                 Enable a system integration
  -fno-sys=[name]              Disable a system integration

Of the two options you propose, I think system_lua as a ?LazyPath seems like the best option.

Ah, I think we should remove system_lua or move it to an invocation of b.systemIntegrationOption(). One quirk here is that in order to work correctly, our lua_all.h file will need a version with #include <lua.h> etc instead of current #include "lua.h"

I think also that we should remove additional_system_headers. Here is my reasoning: if the user needs to include additional headers, they should do this by adding declarations in their lua_user_h.

The correct way to add additional search paths is by adding one or more --search-prefix args.

For example, on my machine I have lua5.5 installed via brew. Making the changes above, if I have pkg-config installed, Zig is able to automagically find and link against lua5.5. If I disable or uninstall pkg-config, Ryan Liptak helped me find the correct --search-prefix invocation: it is --search-prefix /opt/homebrew.

I can make a PR with these changes (and adding angle-bracket versions of lua_all.h and luajit_all.h) later today if there's interest.

I saw that conversation in the zulip, wondered if it was related to this issue. Thanks for taking a look at this!

A PR would be great!

I wonder if the lua_all.h file can just always use the angle bracket versions, instead of needing a different version? I think that's how Lua can include <assert.h> and it finds the local assert.h for the apicheck I recently worked on?

in my testing for #239 just now, #include <lua.h> and #include "lua.h" both seem to work. I don't know if that helps with the initial issue.

Navigation Menu

Repository navigation

Issue with `system_lua` option regarding header location #233

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue with system_lua option regarding header location #233

Description

Activity

natecraddock commented on Oct 25, 2026

robbielyman commented on Oct 30, 2026

natecraddock commented on Oct 30, 2026

robbielyman commented on Oct 31, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

Issue with `system_lua` option regarding header location #233