Build depedencies specific to the compilation target, not host

build-dependencies right now is quite special in that it neither supports feature gating, not does it treat targets the same way as the rest of the code.

Specifically, when I have this in Cargo.toml:

[target.'cfg(target_arch = "xyz")'.build-dependencies]

It doesn't mean the crate is being compiled for xyz target, rather it means the build script will. And without support for features, there doesn't seem to be any way to include a dependency only when the crate is compiled for a specific target.

I was reminded about this after reading Breaking down crate dependencies?

I personally have a problem even with that. I have a GPU shader code and a host-side library code in one crate. build.rs compiles the shader and includes it in the host-side library, but since build dependencies can only be constrained by host platform and not target platform (or features), I end up compiling a whole bunch of stuff for no good reason for shader's build script even though shader doesn't need it.

The reason for such arrangement is similar to arguments in the thread linked above: everything in one place, a bunch of code code shared between shader and host library code (for testing purposes) that I would rather not make public.

Yes, it is workable as is and splitting into multiple crates will help further, but I wish the dependency system was more flexible.

1 Like