Repository navigation
Remove the need for crate-type = ["dylib"] #476
Description
Activity
FYI declaring it as
crate-type = ["lib", "dylib"]will make the CPU build link in the staticlibinstead of using the*.so, but will still needlessly build the*.so.I would love to remove that requirement!
dylibbeing used so rarely has revealed some issues in the past as well, causing weird failures.On
--crate-type dylib: while thecargo rustccmd does have a--crate-type,cargo buildorrunortestdo not. And we primarily rely oncargo buildto build and link everything. So we'd either needcargoto add support for that, or figure out some other way to extract all therlibs we need to link from cargo.Related: In RFC: link-time capabilities, I've suggested this:
Changing link-time capabilities does not require a clean recompile, unlike the current spirv capabilities.
This would also need some kind of custom linking, though the information retrieval from cargo on what needs to get linked would likely be separate from however any variations of linking we do internally.
FYI declaring it as
crate-type = ["lib", "dylib"]will make the CPU build link in the staticlibinstead of using the*.so, but will still needlessly build the*.so.I know, that is exactly what I do right now.
On
--crate-type dylib: while thecargo rustccmd does have a--crate-type,cargo buildorrunortestdo not. And we primarily rely oncargo buildto build and link everything. So we'd either needcargoto add support for that, or figure out some other way to extract all therlibs we need to link from cargo.This is exactly why I thought about
cargo-gpu: even if it is not possible to remove the requirement directly,cargo-gpucould still callcargo rustcinternally and use that option.I thought this is gonna be hard. But after researching the differences between
cargo buildandcargo rustc, I noticed that they're pretty much the same.cargo rustcjust allows you to pass some additional args torustc, like--crate-type=dylib. So this is actually trivially easy: #477Reacted by Nazar Mokrynskyi
Right now for shader crate to compile
crate-type = ["dylib"]is needed to be specified inCargo.toml.This is annoying in case when a library is not just a shader, but also a regular dependency of other crates since this makes compiler generate extra
libshader_crate.soshared objects intarget/{release,debug}.This can be worked around with
cargo rustc --crate-type dylibwhen compiling normally, so maybe codegen backend orcargo-gpucould do something like that transparently and implicitly?Feel free to move this intoHas nothing to do with cargo-gpu.cargo-gpurepository if it makes more sense to be there.