zig build: LibExeObjStep.setOutputDir seemingly no longer affects export headers

[iguessthislldo]

To try to keep up with the changes in Zig, I'm upgrading my project from 0.4.0 to the current master build available as of writing, 0.4.0+f01cb8cc. I'm having an issue with building my project though.

As I'm slowly transitioning the project from C to Zig, I want to be able to expose exported C headers from the Zig sources to the C sources by outputting them to a known location. I did this using LibExeObjStep.setOutputDir on the zig sources. It put the header and object files in the expected places in 0.4.0, but only puts the object files in the expected places using the current prebuilt master, even though I can see the header got generated in zig-cache. These missing headers are causing the build to fail.

I have attached my build.zig file and build output. I'm assuming the argument warnings are a side effect of some sort of argument passthrough. I am of course open to an alternative to this entire approach that I might be missing.

[andrewrk]

The warnings are #2741.

As for the rest of your build.zig file, here are my suggestions:

--- old/build.zig.txt	2019-08-04 16:59:59.809352532 -0400
+++ new/build.zig.txt	2019-08-04 17:04:08.831390909 -0400
@@ -63,7 +63,6 @@
     ZSource.init(p_path, "cga_console"),
     ZSource.init(k_path, "io"),
 };
-var z_objects = [_]?*std.build.LibExeObjStep{null} ** z_sources.len;
 
 const boot_path = t_path ++ "iso/boot/";
 
@@ -72,26 +71,23 @@
     defer arena.deinit();
     const alloc = &arena.allocator;
 
+    const target = Builder.Target{
+        .Cross = Builder.CrossTarget{
+            .arch = .i386,
+            .os = .freestanding,
+            .abi = .gnu,
+        },
+    };
+
     // Kernel
     const kernel = b.addExecutable("kernel.elf", k_path ++ "kernel.zig");
-    kernel.setOutputDir(tk_path);
     kernel.setLinkerScriptPath(p_path ++ "linking.ld");
-    kernel.setTarget(builtin.Arch.i386, builtin.Os.freestanding, builtin.Abi.gnu);
+    kernel.setTheTarget(target);
 
-    var i: usize = 0;
     for (z_sources) |z_source| {
-        z_objects[i] = b.addObject(z_source.name, z_source.source);
-        if (z_objects[i]) |z_object| {
-            z_object.setTarget(builtin.Arch.i386, builtin.Os.freestanding, builtin.Abi.gnu);
-            kernel.step.dependOn(&z_object.step);
-            kernel.addObject(z_object);
-            z_object.setOutputDir(z_source.dir);
-            warn("{}\n", z_object.getOutputHPath());
-            fs.makePath(alloc, z_source.dir) catch |err| {
-                warn("Error making directory {}: {}\n", z_source.dir, @errorName(err));
-            };
-        }
-        i += 1;
+        const obj = b.addObject(z_source.name, z_source.source);
+        obj.setTheTarget(target);
+        kernel.addObject(obj);
     }
 
     for (c_include_dirs) |dir| {
@@ -104,7 +100,7 @@
         kernel.addCSourceFile(c_source, c_args);
     }
 
-    b.default_step.dependOn(&kernel.step);
+    kernel.install();
 
     // TODO: programs/test_prog
 }

Let me know how this goes. If issues come up I'd prefer to improve zig build rather than having you work around them in your build.zig file.

[iguessthislldo]

Target and CrossTarget are in build, not Builder, so that didn't compile as written, but besides that it builds and my OS boots, thanks!

As a side note, I got a failed assert after this:

when analyzing /mnt/arch/data/development/concepts/georgios/kernel/platform/zplatform.zig:42:7: assertion failed. This is a bug in the Zig compiler.
???:?:?: 0x7ff1d2f13f79 in ??? (???)


???:?:?: 0x7ff1d2ee19ab in ??? (???)

Which is:

pub fn initialize_io() void {
    io.console_in = io.new_file() catch |e| null; // This line is 42
    io.console_out = io.new_file() catch |e| null;
}

This variable isn't being used at the moment so I could comment it out and every compiles. Do you want me to create a new issue for this?

[andrewrk]

Target and CrossTarget are in build, not Builder, so that didn't compile as written, but besides that it builds and my OS boots, thanks!

Ah right. Great, glad to hear it.

Do you want me to create a new issue for this?

Yes please, especially if you can provide a way for me to reliably reproduce it.