-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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 system has no way to handle generated header files #10089
Comments
Isn't one of the members of |
Yes, that's my point. |
Alright, but that doesn't mean there is no way to handle generated header files as a build dependency; you would just need to define a step that depends on a file being generated (e.g., Or do you mean that the functionality provided in |
Interesting workaround, I'll give that a shot. Would still be nice to be able to do it directly, like you can for most other things (eg. generated C sources are no problem, you can just call |
I came up with a pretty simple general-ish solution that solves for this problem, and mayhaps others: pub fn addClosureStep(b: *std.build.Builder, name: []const u8, comptime function: anytype, args: std.meta.Tuple(@typeInfo(@TypeOf(function)).Fn.args)) *ClosureStep(function) {
return ClosureStep(function).create(b.allocator, name, args) catch unreachable;
}
pub fn ClosureStep(comptime function: anytype) type {
const Function = @TypeOf(function);
const ArgsTuple = std.meta.ArgsTuple(Function);
return struct {
const Self = @This();
step: std.build.Step,
args: ArgsTuple,
pub fn create(allocator: *std.mem.Allocator, name: []const u8, args: ArgsTuple) !*Self {
const result = try allocator.create(Self);
errdefer allocator.destroy(result);
result.args = args;
result.step = std.build.Step.init(.custom, name, allocator, Self.make);
return result;
}
pub fn make(step: *std.build.Step) anyerror!void {
const self = @fieldParentPtr(Self, "step", step);
@call(.{}, function, self.args);
}
};
}
You could then do something like: // ...
const translate_c_add = b.addTranslateC(.{ .path = b.pathFromRoot("c/add.h") });
const add_include_dir_of_file_source = addClosureStep(b, "add-include-dir", struct {
fn addIncludeDirOfFileSource(target: *std.build.LibExeObjStep, source: std.build.FileSource) void {
target.addIncludeDir(std.fs.path.dirname(file_source.getPath(target.builder)).?);
}
}.addIncludeDirOfFileSource, .{ .@"0" = exe, .@"1" = translate_c_add }); // ignore this, it's just a work around for '.{ exe, translate_c_add }' not coercing to 'std.meta.ArgsTuple(@TypeOf(function))' for whatever reason.
exe.step.dependOn(&add_include_dir_of_file_source.step);
// ... I've tried it, and it certainly seems to work. Don't know if something like this is warranted in |
Related PR, but not closing issue yet: #13742 |
See #14382 |
Any update on this? |
@Ev1lT3rm1nal #13742 and #14382 got implemented. I think that means this issue is fixed. Do you have a use case not covered by those? |
Some software written in C generates header files at build time (eg. to embed a file using
xxd -i
). To be able to build this software properly, the Zig build system needs to handle this.It's possible to hardcode a path and always put the generated file in the same place, but ideally
FileSource
could be used (thoughFileSource
isn't really meant for generated directories, so maybe just something similar).The text was updated successfully, but these errors were encountered: