`sdl2-sys` build script relies on Cargo internals

[ranger-ross]

Cargo is planning to restructure the file structure of the build-dir.
See tracking issue rust-lang/cargo#15010 for more information.

The build script for sdl2-sys will be impacted by this change.

[antonilol]

The problem looks to be with find_cargo_target_dir in build.rs:

rust-sdl2/sdl2-sys/build.rs

Line 427 in bc14e03

fn find_cargo_target_dir() -> PathBuf {

If I understand correctly #796 fixed something by placing dynamically linked libraries in the same directory as the generated executable and needed to know that location.

I think it is possible to update this sketchy function to also work with -Zbuild-dir-new-layout, but it would still depend on cargo internals.

[ranger-ross]

I think it is possible to update this sketchy function to also work with -Zbuild-dir-new-layout, but it would still depend on cargo internals.

That is understandable.
Unfortunately Cargo does not have a way to expose a lot of information about the build directory so there are valid uses cases that need rely on the cargo internals.

Note that we are still iterating on the file structure of the new layout and I plan to make some more changes before calling for stabilization.

[epage]

We have rust-lang/cargo#13663 for providing an official way for staging final artifacts. Until then, you could hack things up to work with both the old and new build-dir layout.

A couple things to note:

• We are likely to change the build-dir layout again
• Technically, the build script is already broken but that requires users opting in to a Cargo feature. Cargo has stabilized splitting out build.build-dir (intermediate artifacts) out of build.target-dir (final artifacts). In the future we may change the default so users have to opt-out (Move build-dir out of the workspace to cargo-cache-home by default rust-lang/cargo#16147) but that would likely be blocked on Allow build scripts to stage final artifacts rust-lang/cargo#13663 as there wouldn't be a way to find the target-dir from the build-dir.

[epage]

Is rust-lang/cargo#3856 at all relevant to this?

[antonilol]

We have rust-lang/cargo#13663 for providing an official way for staging final artifacts.

I think this is what is actually needed because windows would want dynamic libraries in the same directory as the binary.

Is rust-lang/cargo#3856 at all relevant to this?

I don't know, I did not know Rust back then :)

[Cobrand]

Surely we can't be the only crate that uses .dll at loading time out there. The problem in the end is that on windows, if the .dll isn't in the same directory as the ran program, it will fail to find the .dll

Note that on windows we can also set PATH env variable so it loads .dll from there. From the build.rs we can print cargo::rustc-env=VAR=VALUE to set an env variable to the ran program, and we could probably do that for PATH as well. Don't know it that works though, would need to test it. But if it does work, I think it's a viable alternative which would work pre and post change.

But there is another problem: emscripten. It also uses target_dir to do some kind of symlink, and I'm not knowledgeable enough if there is something akin to PATH on emscripten that would solve our issue.

[epage]

For default feature flags on Linux there were only a couple of build scripts that failed with this change.