Jakub Konka f2bf1390a2 macho: fix linking of dylibs and frameworks
Previously, I have incorrectly assumed that with two-level namespace
we only need to link in dylibs/frameworks that actually export symbols
which are undefined in the linked image. Turns out, regardless of
whether we link with two-level namespace (default on macOS) or a
flat namespace (more common on other platforms), we always need to
put the dylibs/frameworks as specified by the user from the linker
line into the final linked image.
2021-08-10 08:13:07 +02:00

35 lines
1.1 KiB
Zig

const std = @import("std");
const Builder = std.build.Builder;
const CrossTarget = std.zig.CrossTarget;
fn isRunnableTarget(t: CrossTarget) bool {
// TODO I think we might be able to run this on Linux via Darling.
// Add a check for that here, and return true if Darling is available.
if (t.isNative() and t.getOsTag() == .macos)
return true
else
return false;
}
pub fn build(b: *Builder) void {
const mode = b.standardReleaseOptions();
const target = b.standardTargetOptions(.{});
const test_step = b.step("test", "Test the program");
const exe = b.addExecutable("test", null);
b.default_step.dependOn(&exe.step);
exe.addCSourceFile("main.c", &[0][]const u8{});
exe.setBuildMode(mode);
exe.setTarget(target);
exe.linkLibC();
// TODO when we figure out how to ship framework stubs for cross-compilation,
// populate paths to the sysroot here.
exe.linkFramework("Cocoa");
if (isRunnableTarget(target)) {
const run_cmd = exe.run();
test_step.dependOn(&run_cmd.step);
}
}