Use of env vars like CFLAGS doesn't appear to support cross compilation

[codyps]

This is a re-post/elaboration of a comment I made on reddit

Looking at the use of CFLAGS, etc, env variables, it would be a good idea to mirror the pattern used in the cc crate. From the cc readme:

Each of these variables can also be supplied with certain prefixes and suffixes, in the following prioritized order:

1. <var>_<target> - for example, CC_x86_64-unknown-linux-gnu
2. <var>_<target_with_underscores> - for example, CC_x86_64_unknown_linux_gnu
3. <build-kind>_<var> - for example, HOST_CC or TARGET_CFLAGS
4. <var> - a plain CC, AR as above.

We used this specific mechanism (of resolving most specific to least specific without combining/appending) to best support the cross compilation of C code.

The relevant code in inline-c appears here:

inline-c-rs/src/run.rs

Lines 149 to 162 in 7bd0f5e

	let get_env_flags = |env_name: &str| -> Vec<String> {
	variables
	.get(env_name)
	.map(|e| e.to_string())
	.ok_or_else(|| env::var(env_name))
	.unwrap_or(String::new())
	.split_ascii_whitespace()
	.map(|slice| slice.to_string())
	.collect()
	};
	command.args(get_env_flags("CFLAGS"));
	command.args(get_env_flags("CPPFLAGS"));
	command.args(get_env_flags("CXXFLAGS"));

Given the desire to integrate CFLAGS/etc that are provided by the program rather than the environment, I'm not sure exactly what should be done here. The CFLAGS/etc from the environment are usually supplied in order for compilation to be functional. Given this, it seems unwise to have program supplied values replace those from the environment. Appending the program supplied values to the environment supplied values might be the best choice.

Additionally, it would be good to examine the splitting methodology used for these variables. In some cases, CFLAGS/etc may contain spaces. This is more common on windows when one might need to provide a path to some directory within the LDFLAGS or CFLAGS (or for plain CC).

On a related note: the handling of LDFLAGS using -Wl probably isn't compatible with how other users interpret LDFLAGS (which are normally passed to the link step without extra munging).

[Hywan]

Thanks for the proposal. I didn't design inline-c for cross-compilation situations, but rather for testing purposes. What's your usecase with cross-compilation? It sounds fun.

The splitting strategy for environment flags are the same than in cc.

I agree that LDFLAGS is not best used here. I'll rework that. We have an issue on Windows with it for instance, cf #8.

[codyps]

I tend to write code that needs to be runnable under open-embedded derived platforms (and build-able via oe's bitbake or oe's sdk). The way oe (and the oe sdk) works is that it provides CFLAGS/LDFLAGS/etc that cause the linking of libraries/etc from a particular sysroot when cross compiling.