-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix dynamic search path for build scripts #3974
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @brson (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
Thanks! Could you refactor this to share an implementation with compilation.rs as well? |
This no longer passes tests. Do you know where to get the correct target directory path from?
doesn't seem to be the right thing. (I assume when you said you wanted to use the same code in both cases you meant that the build script case also should have the "don't add paths outside the target dir" logic.) |
|
Oh so that bug I believe is because the prefix needs to be with Could you actually avoid though making |
FYI, it does not work with Kind::Host either, I think because we are relative to 'unit'. Where do I get the path to |
Hm looking back the usage of Looking at the appveyor failure the test involved is legitimately breaking after this change was applied. Not only is this picking up the |
How does this look? I fixed the test by putting the project that builds the dylib and the project that uses it into a workspace. I'm kinda shocked that the issue #3366 dylib path filtering is not breaking people's builds. It seems like it should at least give a diagnostic, so I left a debug!() in there. |
I'm not sure what is going on, but I get test failures on cargo master that appear related to the failures in this build. I pulled the known good appveyor commit mentioned below (bors building a nightly) and tried to build it and it failed. The appveyor shows it succeeding. I deleted ~/.cargo ~/.multirust and ~/.rustup before starting. I built in a fresh clone of the cargo tree. I'm not sure if there is some other state or config file that you can think of that I need to clean up on my machine or if this is a real issue. OS is Windows 10 1703.15063.138 Thoughts?
|
I thought it might be because I am building using cargo rather than configure/make, but it appears that using cargo works fine in a modified CI build. https://ci.appveyor.com/project/mcgoo/cargo/build/1.0.3/job/xrgse4388abpa9ng The tests that fail are not the same test that fails in the CI for this PR so this may just be a strange coincidence. Any advice on what I need to do to get the tests working much appreciated. |
Ok, this looks good to me now and the tests pass on the CI server at least. |
Looks great to me, thanks! Want to squash the commits and I'll r+? |
a236e99
to
125fdd8
Compare
☔ The latest upstream changes (presumably #4008) made this pull request unmergeable. Please resolve the merge conflicts. |
Ah sorry if I missed this! Want to resolve the conflicts? Feel free to ping me when the PR is ready as unfortunately github doesn't send out notifications when it's force-pushed :( |
ddbf1a7
to
cb348bd
Compare
Make dynamic library search path handling for build scripts mirror the behaviour for cargo run etc. -L paths are taken and stripped of the native= and similar prefixes and added to the dynamic library search path if they are inside the target dir. Resolves rust-lang#3957
cb348bd
to
b8158cf
Compare
ping @alexcrichton |
@bors: r+ |
📌 Commit b8158cf has been approved by |
fix dynamic search path for build scripts fixes #3957
☀️ Test successful - status-appveyor, status-travis |
Fix add_plugin_deps-related tests. These tests were modified in #3974 in such a way that they stopped testing the `add_plugin_deps` code path. The tests can't be directly reverted because #3651 changed it so that dylib paths must be within the root output directory. I compromised by just copying the dylib into `$OUT_DIR`. Closes #6318.
fixes #3957