-
Notifications
You must be signed in to change notification settings - Fork 32
Open
Description
The variable export script currently has this content more or less:
export PATH="/home/svenstaro/.espressif/tools/xtensa-esp32-elf-clang/esp-13.0.0-20211203-x86_64-unknown-linux-gnu/bin/:$PATH"
export LIBCLANG_PATH="/home/svenstaro/.espressif/tools/xtensa-esp32-elf-clang/esp-13.0.0-20211203-x86_64-unknown-linux-gnu/lib/"
export PIP_USER=no
This will currently make build.rs
-driven cross-compilation impossible since the CC
and AR
are unset and so a crate such as cc
will still use the host's regular cc
and ar
commands.
Consider this simple build.rs
:
fn main() -> anyhow::Result<()> {
println!("cargo:rerun-if-changed=c/hello.c");
println!("cargo:rerun-if-changed=target/export-esp-rust.sh");
cc::Build::new()
.file("c/hello.c")
.compile("hello");
embuild::build::CfgArgs::output_propagated("ESP_IDF")?;
embuild::build::LinkArgs::output_propagated("ESP_IDF")
}
This won't compile properly as it stands right now because of the aforementioned reason. I suggest expanding the exported variables to include all of the cross compilation toolchain tools.
In fact, I wonder why this is not being done and whether I'm missing something here.
Consider this:
export CC="xtensa-esp32-elf-gcc"
export AR="xtensa-esp32-elf-ar"
export PATH="/home/svenstaro/.espressif/tools/xtensa-esp32-elf-clang/esp-13.0.0-20211203-x86_64-unknown-linux-gnu/bin/:$PATH"
export LIBCLANG_PATH="/home/svenstaro/.espressif/tools/xtensa-esp32-elf-clang/esp-13.0.0-20211203-x86_64-unknown-linux-gnu/lib/"
export PIP_USER=no
Would allow you to compile and link most simple C programs directly and without further hassle. What do you think?
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
Status
Todo