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

Module file names should be resolved relatively to the referring module #6746

Closed
mzabaluev opened this issue May 26, 2013 · 4 comments
Closed
Labels
A-linkage Area: linking into static, shared libraries and binaries E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.

Comments

@mzabaluev
Copy link
Contributor

With current rustc it's difficult to support automake-style out of tree builds, because when a crate file is compiled outside of its containing directory and it references other modules, the module file paths are resolved relatively to the current directory of the compiler process, not relatively to the referring crate file. Is there any benefit in making the crate assembly dependent on the current working directory?

@bblum
Copy link
Contributor

bblum commented Jul 26, 2013

Nominating backwards-compatible.

@catamorphism
Copy link
Contributor

Needs reproduction. @mzabaluev can you post a small test case?

@catamorphism
Copy link
Contributor

De-nominating for now; we think this actually works.

@mzabaluev
Copy link
Contributor Author

Indeed, it works as of Rust 0.7. Thanks for the update.

mzabaluev added a commit to gi-rust/glib-sys that referenced this issue Jan 24, 2015
It has to be ugly because of rust-lang/rust#6746
mzabaluev added a commit to gi-rust/glib-sys that referenced this issue Jan 24, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-linkage Area: linking into static, shared libraries and binaries E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.
Projects
None yet
Development

No branches or pull requests

3 participants