Easier conversion from `cc::Build` to `cpp_build::Config` ?

[ian-h-chamberlain]

Hi, I recently started looking at using this library as a way to generate tests that cross a C/Rust boundary, and so far it's working pretty well!

In our case, we are already using a cc::Build for some C libraries, so I thought it would be nice if there was a simple way to translate between the two, so we don't have to repeat all of our builder flags, e.g.

    cc::Build::new()
        .compiler(&cc)
        .archiver(&ar)
        .include(&include_path)
        .file(out_dir.join("libctru_statics_wrapper.c"))
        .flag("-march=armv6k")
        .flag("-mtune=mpcore")
        .flag("-mfloat-abi=hard")
        .flag("-mfpu=vfp")
        .flag("-mtp=soft")
        .flag("-Wno-deprecated-declarations")
        .compile("ctru_statics_wrapper");

    cpp_build::Config::default()
        .compiler(cc)
        .archiver(ar)
        .include(include_path)
        .flag("-march=armv6k")
        .flag("-mtune=mpcore")
        .flag("-mfloat-abi=hard")
        .flag("-mfpu=vfp")
        .flag("-mtp=soft")
        .flag("-Wno-deprecated-declarations")
        .build(generated_test_file);

Would you be open to a PR adding a From<cc::Build> implementation for cpp_build::Config? The downside would be adding cc as a public API (I don't think it is currently), but would make maintaining a set of flags/include paths/tools like this a bit simpler.

Thanks!

[ogoffart]

Would you be open to a PR adding a From implementation for cpp_build::Config?

I think that makes sense

The downside would be adding cc as a public API (I don't think it is currently), but would make maintaining a set of flags/include paths/tools like this a bit simpler.

Given that cc has been in the 1.0 for so long and proven to be stable, I think this is not a problem. And probably a good thing to expose it directly