Use @file to pass the --cfg flags to rustc (fixes #22)

[ojeda]

It also helps to avoid spamming the terminal when doing verbose builds.

Signed-off-by: Finn Behrens [email protected]
Signed-off-by: Miguel Ojeda [email protected]

[ojeda]

@kloenk This is the fix you needed.

[ojeda]

I changed a few of the names of several things/variables/etc. to improve clarity (hopefully!).

[ojeda]

@kloenk Since I kept you as the author (as if I had applied your patches in my tree in a ML-based workflow), you need to confirm you agree with the changes I did on your behalf :-)

[kloenk]

So the difference between this and #23 is the use of build.rs right?

What's the direction we want to go with build.rs? I'm more a fan of removing it, as we only have to have bingen, and not some libclang path set.

[kloenk]

LGTM, would rebase #23 to master if this gets merged.

[kloenk]

Would like to remove readlink someday, but does not have to be now

[kloenk]

This creates 2 times the same CFC flag? Does it work? Is cfg!(CONFIG_C) false if X is n? Or is it set to n and so returns true?

[ojeda]

Yeah, it works! cfg holds a multimap, which allows us to do things like this:

#[cfg(not(CONFIG_X))]
pub static CONFIG_X_DISABLED: i32 = 0;

#[cfg(CONFIG_X)]
pub static CONFIG_X_ENABLED: i32 = 0;

#[cfg(CONFIG_X="y")]
pub static CONFIG_X_BUILTIN: i32 = 0;

#[cfg(CONFIG_X="m")]
pub static CONFIG_X_MODULE: i32 = 0;

Since the most common case is checking whether CONFIG_X is enabled in any way (either y or m), I suggested this way in #22 (comment). Thus most code gets the best looking code: #[cfg(CONFIG_X)].

Another option is generating things like CONFIG_X_ENABLED directly instead of using just CONFIG_X, but I thought this mimicked best what C does, looks best for the common case and is guaranteed to not have collisions, e.g. if someone wants to define both CONFIG_X and CONFIG_X_MODULE.

[ojeda]

I should probably copy this example to somewhere in Documentation/rust too.

[ojeda]

So the difference between this and #23 is the use of build.rs right?

Yeah, plus your O=... work/fixes (i.e. they are not here; I undid them to separate the different fixes in different PRs/commits).

What's the direction we want to go with build.rs? I'm more a fan of removing it, as we only have to have bingen, and not some libclang path set.

Let me send the PR and I'll reply to you there.