Support executable compilation

[sfackler]

A common configuration error when using rust-openssl is to reference headers and libraries from different versions which results in weird and hard to track down breakage. I want to handle this by compiling and running a little executable that compares the values of the version encoded in a #define in the headers and a function in the library.

Unfortunately, gcc-rs will currently only build staticlibs.

[alexcrichton]

This is actually pretty intentional today because it's not often possible to actually run the executable that would be generated (e.g. almost all cross compilation scenarios).

The "most robust" thing I think would perhaps be something like gcc -E and then parsing the output if you just want to learn about various #define constants.

[sfackler]

That's a fair point, but the check I want to make isn't necessary for compilation to continue, and since the vast majority of compilation is not crossed I'm fine with gcc-rs saying "no".

The gcc -E approach isn't going to work because I need one #define out of a header and the result of calling SSLeay() at runtime.

[alexcrichton]

So this is one reason I added the get_compiler API where you could get the tool itself and add your own arguments and such, perhaps that would be good enough for now rather than adding a first-class API?

[AndiDog]

I also just wanted to suggest this feature. If you think cross-compilation is really a problem, you could offer the API to only compile executables to the host architecture (not to the cross-compiled architecture), which is the exact use case of @sfackler and me (dynamic build configuration).

[alexcrichton]

I'm going to close this as it's not currently my intention to support this in this library as this crate is primarily for build scrips and building native code, especially handling the cross-compile cases.

[quadrupleslap]

It's a very niche use-case, but I'm pretty sure generating executables would be very useful for my build script - I need to generate a second executable to be called by the Chromium Embedded Framework on the target platform.

Edit: Also, the get_compiler API @alexcrichton linked above doesn't seem to exist. Was it removed? Nevermind, that link is ancient, it still works.

[quadrupleslap]

Does this work across platforms though? I'm not getting any target triples.

let cc = cc::Build::new();
let mut cmd = cc.get_compiler().to_command();
cmd.args(&["-l", "cef", "-o"]);
cmd.arg(out_dir.join("cef-slave"));
cmd.arg("foreign/cef-slave.c");
assert!(cmd.status().unwrap().success());

[BenLeadbetter]

Seems like an obvious missing feature to me. How else would one support unit test executables for C/C++ libraries built with cc ?

Best solution I could come up with is a pretty ugly workaround.

[madsmtm]

Seems like an obvious missing feature to me. How else would one support unit test executables for C/C++ libraries built with cc ?

You wouldn't (or you'd build the feature upon cc-rs yourself, as you've done).

The problem is that building executables, just like building shared libraries (see e.g. #1582), requires invoking the linker. And the linker is like a whole separate program with its own slew of configuration flags and requirements, it's a deep rabbit hole that we don't want cc-rs to go down into.

Someone could make a ld-rs for this use-case, but it's not in scope for cc-rs.