Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build step options ignored by imported file #4

Open
pedromsilvapt opened this issue Aug 27, 2020 · 2 comments
Open

Build step options ignored by imported file #4

pedromsilvapt opened this issue Aug 27, 2020 · 2 comments

Comments

@pedromsilvapt
Copy link
Contributor

Hi again. Sorry for bothering so much all of a sudden, it's just that I've found this project and really wanted to be able to use it for one of my projects.

Regarding the issue, I don't know if you've thought about this before, but since we are importing the file during build, any configurations specified in the build steps do not apply. For example, in my build file I have this line:

lib.addPackagePath("clap", "lib/zig-clap/clap.zig");

But when using @import in the build phase, the code will not be able to find the package. Not only that, but if any library needs to be linked against, the current solution does not work.

So my question is, have you though about any possible solutions for this problem? Ideally, the build system would offer a way to inspect any symbols that were compiled in a build step, and allow the users to hook into that somehow.

Right now, I'm not entirely sure what the best solution would be honestly. If we could somehow use comptime in the actual source files to use reflection and generate some sort of type definition files (in JSON or something else), we could then read it in the build file instead of importing and using reflection there. Don't really know, I'm just spitballing ideas here.

@suirad
Copy link
Owner

suirad commented Aug 28, 2020

Yea the "real-fix" for this would be to actually parse .zig files looking for the exports, rather than doing comptime reflection. I would say that a work around for this would be to have a defined file for library exports. It could use some work.

@pedromsilvapt
Copy link
Contributor Author

One possible solution I thought of. Assuming the user was building a lib like this:

const lib = b.addSharedLibrary("libname", "src/lib.zig", version);
lib.setTarget(target);
lib.setBuildMode(mode);
// Any additional config
lib.install();

I wonder if a solution could not be something like: add a main() to src/lib.zig and there do something like:

pub fn main () void {
    const gen = header_gen.HeaderGen(@This()).init();
    gen.exec(header_gen.C_Generator);
}

And then in the build, they would have to create an executable and preferably auto-execute it afterwards.

const exe = b.addExecutable("libname-headergen", "src/lib.zig");
exe.setTarget(target);
exe.setBuildMode(mode);
// Any additional config...
exe.install();

const run_cmd = exe.run();
run_cmd.step.dependOn(b.getInstallStep());

const run_step = b.step("headergen", "Generate headers");
run_step.dependOn(&run_cmd.step);

The user could then run zig build headergen and it would generate the headers, and respect the compilation options set by the user. We could probably even include a utility function to setup this build steps automatically, for convenience.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants