-
Notifications
You must be signed in to change notification settings - Fork 474
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
Print Out SDL2 Include Directory in sdl2-sys Build Script #968
Conversation
Great job! Question though, what do you mean by
Where does |
That is how cargo passes the information forward. All crates that have a This is all documented in the cargo book, though the documentation is kind of poor and you have to piece the story together though the examples and a variety of different sections. Here, the second to last paragraph here, and a bit more clearly in the example here. Maybe the next thing I should do it touch up the docs.... 😄 |
Really interesting, I didn't know about that. You are right, perhaps one or two sentences in the readme explaining what you've just said (or linking to this issue) could help someone with your same use case! |
Is this issue worthy of the changelog also? If so where should I put it? |
In the changelog create a "v0.34" or "unreleased" entry above all the rest, and I'll tidy it up when I push an actual release then. Thanks! |
Perfect, thanks! |
Print Out SDL2 Include Directory in sdl2-sys Build Script
In order to facilitate using the includes provided/found by
sdl2-sys
in other*-sys
crates, I have added print statements which set the "include" key to the path to the include folder that has either been provided or found.This can be accessed through the environment variable
DEP_SDL2_INCLUDE
in all crate build scripts which directly depend onsdl2-sys
, transitives are not affected.If there are multiple include directories, they are separated by a
:
.A use case can be found here where I must pass the header directory to
cc
to build c++ code which depends on SDL2.I have tried to make as few changes as possible to the build script, however I did make two changes that shouldn't affect the usability of it at all:
generate_bindings
to no longer be generic, as every single instance was being called withS = String
. This started because I wanted to use.join(":")
on the slice, but that requires something that isBorrow<str>
notAsRef<str>
. As borrow is a newer feature, I didn't know your minimum rustc version, and all invocations were withString
, I just went ahead and removed the generic.All of the particulars about the PR can be changed if needed to fit style, usability, etc. I have verified that my own fork works as expected for downstream crates.
It might be worthwhile to add this to documentation as well, though I don't know if that is deserving of its own PR.
Closes #967