Step.Compile.installHeader and related functions don't install headers as intended

[castholm]

Zig Version

0.12.0-dev.409+48e2ba3b3

Steps to Reproduce and Observed Behavior

Step.Compile.installHeader, Step.Compile.installLibraryHeaders and similar functions are intended to mark installing the headers a dependency of installing the compiled artifact, i.e. the headers are bundled with the compile step and are automatically installed when the compiled artifact is installed.

Currently, however, these functions add themselves to the default install top-level step (b.install_tls) instead of registering themselves with the compile step, which results in the headers not being installed if the compiled artifact is installed via a custom top-level step.

If I have the following code in my build.zig

const foo = b.addStaticLibrary(.{
    .name = "foo",
    .target = target,
    .optimize = optimize,
});
foo.installHeader("hello.h", "hello.h");

const my_step = b.step("my_step", "...");
my_step.dependOn(&b.addInstallArtifact(foo, .{}).step);

and run zig build my_step, it results in the following files being installed

zig-out/
+-- lib/
    +-- foo.lib

with hello.h missing.

The affected Step.Compile functions are:

• installHeader
• installConfigHeader
• installHeadersDirectory
• installHeadersDirectoryOptions
• installLibraryHeaders

Expected Behavior

The affected functions should bundle the headers with the installed artifacts instead of modifying the global top-level install step.

Given the example input, zig build my_step should install the following files:

zig-out/
+-- include/
|   +-- hello.h
+-- lib/
    +-- foo.lib

[abhinav]

I put up #19139 based on the issue description, but I'm not certain about this behavior.
With that PR, an artifact will install its headers to zig-out/include when it's built even if the library is never installed. That doesn't seem right.

I think the most correct form of this should install the headers only if someone calls addInstallArtifact(lib) (as a dependency of that install step) but I don't see an easy way to do that. There's no other concept of a non-global install step available to the Compile step.
We somehow need the InstallArtifact step from addInstallArtifact to be plumbed to the install operations in Compile.

[castholm]

@abhinav I made a brief attempt at trying to solve this a few weeks ago by changing it so that Step.Compile.installed_headers stores headers in a way that doesn't create additional install steps or modifies the default top-level step. I got a bit distracted and never ended up finishing it. Would you mind if I completed that work, adapted your tests and opened a PR for it?

[abhinav]

@castholm no, absolutely not. Go for it!