These are chat archives for rust-lang/rust

16th
Jul 2015
Thomas Koehler
@Bastacyclop
Jul 16 2015 16:11
I have a build script that needs the location of a native library and its includes, how do I do that ?
I guess there is some way to permit -I and -L flags to be optionally retrieved ?
Erik Hedvall
@Ogeon
Jul 16 2015 16:14
I think that pkg-config can do that for you on Linux. I don't know about other platforms...
Peter Atashian
@retep998
Jul 16 2015 16:15
pkg-config can also be used in msys on Windows
But it definitely will not work for MSVC on Windows.
Thomas Koehler
@Bastacyclop
Jul 16 2015 16:16
I'll check it out, but I never used it before
And it seems a bit restrictive
Erik Hedvall
@Ogeon
Jul 16 2015 16:18
It's not ideal for multi-platform support. I don't know what's best to do
Thomas Koehler
@Bastacyclop
Jul 16 2015 16:20
Maybe I can use an environment variable with cargo ?
Peter Atashian
@retep998
Jul 16 2015 16:23
The ideal solution is to rewrite your dependency in pure Rust
Thomas Koehler
@Bastacyclop
Jul 16 2015 16:36
Okay so I used std::env::var and it works fine by specifying the variable when running cargo.
Not the dream solution but it does the job quite well
Thomas Koehler
@Bastacyclop
Jul 16 2015 16:43
Also, when my g++ [...] command fails (can't find the include files for example), cargo acts like if everything went fine. I'd like cargo to understand and report that the build failed.
How can I do that ?
Peter Atashian
@retep998
Jul 16 2015 16:43
Don't call g++ yourself. Use the gcc crate to build your code for you.
Thomas Koehler
@Bastacyclop
Jul 16 2015 16:45
Thanks
Peter Atashian
@retep998
Jul 16 2015 16:46
It also has the benefit of working on systems where g++ doesn't exist, not even as an alias. For example, msvc on Windows.
Thomas Koehler
@Bastacyclop
Jul 16 2015 16:54
Do I still need to use ar manually ?
Peter Atashian
@retep998
Jul 16 2015 16:54
Nope, gcc handles that for you
Thomas Koehler
@Bastacyclop
Jul 16 2015 17:09
What about the println!("cargo:rustc-link..."); stuff ?
Thomas Koehler
@Bastacyclop
Jul 16 2015 20:59
I've got a macro expanding into a struct and putting #[repr(C)]in front of it. And yet I get a warning "consider adding a #[repr(...)] attribute to the type"
Maybe it's because the struct has a lifetime ?
Erik Hedvall
@Ogeon
Jul 16 2015 21:08
Hard to say without seeing the macro
Erik Hedvall
@Ogeon
Jul 16 2015 21:15
Hmm... It's clearly there. Have you tried without the phantom type or tried to move it to the end of the struct?
Thomas Koehler
@Bastacyclop
Jul 16 2015 21:18
Moving to the end dosen't change
Erik Hedvall
@Ogeon
Jul 16 2015 21:20
On what line do you get the error?
Thomas Koehler
@Bastacyclop
Jul 16 2015 21:21
Thomas Koehler
@Bastacyclop
Jul 16 2015 21:29
Maybe I should make a struct without lifetime and wrap it into another with the phantom data
Erik Hedvall
@Ogeon
Jul 16 2015 21:30
Maybe you have to write extern "C" { at the beginning of the FFI block...
I'm not used to do FFI stuff, so I may be horribly wrong
Thomas Koehler
@Bastacyclop
Jul 16 2015 21:31
Probably the lifetime and phantomd data so
Still the same, and i have a lot of other structs using #[repr(C)] and they work
Erik Hedvall
@Ogeon
Jul 16 2015 21:33
Try making a separate struct, then. It may be that phantom data doesn't play well with #[repr(C)]