Add ability to dump equivalent commandline flags from builder

[fitzgen]

This would be really useful for being able to reproduce (and then minimize with creduce) bindgen failures inside build.rs.

I find myself doing a hacky job of this manually with stylo right now.

[fitzgen]

I can mentor an ambitious contributor who might want to take this on. Leave a comment if that is you.

[basic-bgnr]

@fitzgen I volunteer. What's next ?

[fitzgen]

@basic-bgnr great!

In src/lib.rs there is the Builder struct, which provides a programmatic API for configuring bindings generation. The other API is the command line API. When debugging bindgen behavior with creduce, it is often easier to use the command line API. So, it would be great to have a Builder::command_line_flags() method that returned a Vec<String> representing the equivalent command line flags for the given Builder instance.

See src/options.rs for how command line flags get translated into a Builder, which is the reverse transformation that we are interested in.

We can test it by adding a tests module to the bottom of the file:

#[cfg(test)]
mod tests {
    #[test]
    fn a_unit_test_function() {
        // ...
    }
}

Let me know if you have any questions or if any of that isn't clear. Thanks! :)

[basic-bgnr]

@fitzgen OK great, I'll get to it shortly.

[basic-bgnr]

@fitzgen, I'm still reading the source, will get into actual writing by tonight. Is there any deadline for completion?
LIBCLANG_PATH was peculiar to solve during building with cargo.

[fitzgen]

@basic-bgnr no deadline, this is just a useful little feature, not anything anyone is blocked on.

LIBCLANG_PATH was peculiar to solve during building with cargo.

Did you end up getting a build + tests up and running OK? Is there anything we should add/change in CONTRIBUTING.md to make this process more clear?

Note that this is only needed if you're running bindgen with a libclang that isn't the system libclang or isn't on the system lib path.

[basic-bgnr]

@fitzgen sorry, the issue was not with building but running. Nothing too much of hassle, but i had to create symbolic link of libclang-3.8.so.1 (on my current machine) to libclang.so.1 to get it running.

[fitzgen]

@basic-bgnr how are things going? Any questions I can answer for you?

[basic-bgnr]

@fitzgen nothing right now. Just wondering whether my solution is little bit on the ugly side. How long do you think in terms of LOC should the solution be?

[fitzgen]

@basic-bgnr I'm not sure, but I suspect there might be a fair bit of boilerplate. If you want more specific feedback, its easiest to open a work-in-progress PR so we can talk about the code there.

[basic-bgnr]

@fitzgen ok