Skip to content
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

Write generated bridge files to OUT_DIR as-is #214

Closed
wants to merge 1 commit into from

Conversation

stoically
Copy link

@stoically stoically commented May 31, 2020

Possible way to fix #213. Currently breaks things, if this is something that might make sense I'm happy to look into making it work.

This requires consumers to add

let out_dir = env::var("OUT_DIR").unwrap();
// ...
cxx.include(out_dir);

to their build script.

@stoically stoically changed the title refactor: always write generated files to out_dir as-is Write generated bridge files to out_dir as-is May 31, 2020
@stoically stoically changed the title Write generated bridge files to out_dir as-is Write generated bridge files to OUT_DIR as-is May 31, 2020
Copy link
Owner

@dtolnay dtolnay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR!

As you can tell, the Cargo story is not completely worked out yet; I have mostly been developing using Bazel and using Buck at work. I will play around with your crate and try to figure out what the right behavior should be. I think this PR is in the right direction but I think we would want to use a subdirectory of OUT_DIR to avoid disrupting other things that the crate's build script might be doing in OUT_DIR. Also I want crates to be able to include generated headers from their dependencies, so only putting them in OUT_DIR would not be sufficient because crates generally do not get to access other crates' OUT_DIR. So we'd want generated headers symlinked to a predictable place elsewhere in the target dir and probably namespaced by the dependency's crate name.

Copy link
Owner

@dtolnay dtolnay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I published cxx and cxx-build 0.4, which hopefully fixes all of the brittleness in the Cargo-based workflow, including #213. I know it's been a really long time but if you are still interested in this, would you be able to give 0.4 a try with your crate?

@stoically
Copy link
Author

Works like a charm now. Thanks a lot for working on this! (And sorry that I didn't pick up my slack here after your fast response)

@stoically stoically closed this Sep 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cannot #include gen.rs.h reliably when building with cargo due to dynamic out location
2 participants