Hi!

We allow you to choose any path when constructing the objects directly via Dxc::new(Some("...")) and Dxil::new(Some("...")). No need to use any crate to help find it I think, relying on the system and LD environment variables should be enough. Semantics are different between Windows and Linux though, where Windows looks relative to the executable and Linux relative to PWD (in addition to other env vars and/or config steering LD). Either way we could drop the ./ IMO (for now I also have a libdxcompiler.so -> /usr/lib/libdxcompiler.so symlink 😬).

I do intend to remove the compile_hlsl() etc helper one day, or at the very least inline its error helpers into fn compile(), but it's been tricky with so many functions returning HRESULT and there being no precedent when or not the returned error string is set and could be bubbled up to the user ¹. That's the only thing you'll have to copy/reimplement when using the Dxc and Dxil implementations directly.

Just running into a relatedly funny bug. When calling Dxc::new(Some("libdxcompiler.so")) on a Linux machine, but that relative filename isn't a file (doesn't exist at all) relative to $PWD. So this code runs into the else path and concatenates that ./libdxcompiler.so path...:

And ends up with:

panicked at 'called `Result::unwrap()` on an `Err` value: HassleError(LoadLibraryError { filename: "libdxcompiler.so/./libdxcompiler.so", inner: DlOpen { desc: "libdxcompiler.so/./libdxcompiler.so: cannot open shared object file: No such file or directory" } })'

😂

I think the only way to fix this cleanly is to stop pretending lib_path could either be a dir or filename.