Zig build-exe and the module path

i’m invoking zig build-exe relative/path/to/main.zig, but my main.zig needs to @import other files that are also relative to my current working directory

needless to say, i receive an error that my import of ../../../etc/foo.zig is outside of the module path…

using zig build-exe, is there a way i can finess this???

You can add foo as module and @import("foo").
The command line to invoke build-exe becomes:

zig build-exe --dep foo -Mroot=relative/path/to/main.zig -Mfoo=/path/to/etc/foo.zig

Where:

  --dep [[import=]name]     Add an entry to the next module's import table
  -M[name][=src]            Create a module based on the current per-module settings.
                            The first module is the main module.
                            "std" can be configured by omitting src
                            After a -M argument, per-module settings are reset.

Also, as another trick you can pass --verbose when invoking zig build, that will show you how it invokes zig build-exe behind the scenes.

Everything that you do through a build script can also be done via direct invocations.

1 Like

my use-case is a little unusual, in that i have a tree with LOTS of .zig source files that @import on another using paths relative to the root of that tree…

i then have my main.zig (which is actually generated into a sub-directory buried deep into that tree) which i then want to zig build-exe

needless to say, were this (generated) main.zig placed at the ROOT of this tree, i would have no problems…

given the sheer number of .zig sources under my tree, making each of them modules is somewhat impractical…

it turns out that my generated main.zig is basically a one-liner… silly as it sounds, is there a way for zig build-exe to actually have one of its file arguments actually come from stdin???

as an aside, is there a way to accomplish this within a build.zig file – that is, to build some main.zig but have the “root” of the build placed in some parent directory???

Given that this is practical to do, it seems to me the short path is to do it.

i’ve done just that, for expediency… but now i have a somewhat related question, now that i have my tree of .zig files rooted at the folder containing my main.zig

while all of the .zig files within my tree can @import one another using paths relative to the ROOT, i have one “special” file that all others will import (not unlike "std")… it just so happens that this file is somewhere INSIDE my tree…

following the suggestions by @dimdin , do i effectively make this special file its own module – which can now be imported by using just its own root-name??? is there a problem if one module tree is in fact embedded under another???

presumably my special file (now its own module) can only import files using relative paths within ITS rooted tree… but since this module root ALSO contains a subset of the files under my original main.zig root, what “root” actually prevails when analyzing one of the common .zig files???

Should not be a problem as long as no other file tries to import it directly.

That will cause a “file in multiple modules” error. A Zig file can only belong to one module at a time.

See if you can make that file and all other “related” files a self-contained module, otherwise then you don’t want that to be a module at all, just keep importing it using relative paths within your project.

this all makes sense…

but just to increase my understanding, could the root of my main.zig module actually be in some parent folder (../../../) of main.zig itself???