phil-opp / cargo-post Goto Github PK

Currently, it appears that cargo-post ignores the $CARGO_BUILD_TARGET environment variable, resulting in it passing incorrect CRATE_TARGET/CRATE_TARGET_TRIPLE/CRATE_OUT_DIR variables to the post-build script.

Pseudo-related to #2, given that the environment variable is another way of specifying the build.target configuration key.

Read .cargo/config files (recursively upwards in the tree until a file is found).

This is required for taking build.target default targets into account for the passed CRATE_* environment variables.

When I run cargo post build in a workspace where each member has their own post_build.rs I get this:

thread 'main' panicked at 'Please specify a `--package` argument', src/main.rs:109:17
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::default_hook
   5: std::panicking::rust_panic_with_hook
   6: std::panicking::begin_panic
   7: cargo_post::run_post_build_script
   8: cargo_post::main
   9: std::rt::lang_start::{{closure}}
  10: std::rt::lang_start_internal
  11: std::rt::lang_start
  12: main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I have no idea what it means or where to specify this --package parameter (and what value it should take). :)
Could you clarify and maybe add some note to the REAMDE/docs?

From my Cargo.toml:

[package.metadata.cargo-post.dependencies]
depgraph = "0.3.0"
aftereffects-sys = { path = "../crates/aftereffects-sys" }

[dependencies]
aftereffects-sys = { path = "../crates/aftereffects-sys" }

depgraph is found, aftereffects-sys is not found by cargo post (but found by cargo).

As you can see the location of this crate for the package.metadata.cargo-post.dependencies section is specified matching that of the dependencies one exactly.

Particularly useful for versioning post-build artifacts are all CARGO_PKG_VERSION_* variables that regular cargo knows.

This is probably as easy as:

1. Run cargo build
2. Rust post_build.rs
3. Run cargo run

When using workspaces where you might have one build depend on another, it makes sense that you may want to use post-build on that, so that the dependencies can use the modified post-build. However, currently it post builds only after the whole workspace's cargo build is complete.

I am currently building a cross-compiled aarch64-unknown-none application. I would like to use post_build.rs to specify some additional post-build linker commands.

I have the following config.toml in my project:

[build]
target = "aarch64-unknown-none"

[target.aarch64-unknown-none]
rustflags = ["-C", "link-arg=linker.ld"]

This specifies the target as aarch64-unknown-none while building.

When I define a build.rs script, cargo is intelligent enough to know NOT to build build.rs for the aarch64-unknown-none target. Instead, it uses my host machine's triple.

post_build.rs, however, appears to be built for the project's build target. This makes the post_build executable unable to run on on my host, rendering it unusable.

In this case, I would expect cargo post build to build post_build.rs for my host triple, NOT the target triple for the overall project.

Some error output to indicate the issue:

   Compiling post-build-script v0.1.0 (C:\Users\finne\Repositories\rust-aarch64-kernel\target\post_build_script_manifest)
error[E0463]: can't find crate for `std`
  |
  = note: the `aarch64-unknown-none` target may not support the standard library
  = note: `std` is required by `post_build_script` because it does not declare `#![no_std]`
  = help: consider building the standard library from source with `cargo build -Zbuild-std`

error[E0463]: can't find crate for `std`
 --> C:\Users\finne\Repositories\rust-aarch64-kernel\post_build.rs:1:5
  |
1 | use std::process::Command;
  |     ^^^ can't find crate
  |
  = note: the `aarch64-unknown-none` target may not support the standard library
  = help: consider building the standard library from source with `cargo build -Zbuild-std`

error: cannot find macro `panic` in this scope
  --> C:\Users\finne\Repositories\rust-aarch64-kernel\post_build.rs:13:9
   |
13 |         panic!("cargo objcopy command failed: {:?}", output);
   |         ^^^^^
   |
help: consider importing this macro
   |
1  + use core::panic;
   |

error: cannot find macro `println` in this scope
 --> C:\Users\finne\Repositories\rust-aarch64-kernel\post_build.rs:4:5
  |
4 |     println!("cargo:rustc-env=TARGET=x86_64-pc-windows");
  |     ^^^^^^^

error[E0463]: can't find crate for `std`
 --> C:\Users\finne\Repositories\rust-aarch64-kernel\post_build.rs:7:18
  |
7 |     let output = std::process::Command::new("cargo")
  |                  ^^^ can't find crate
  |
  = note: the `aarch64-unknown-none` target may not support the standard library
  = help: consider building the standard library from source with `cargo build -Zbuild-std`

error: `#[panic_handler]` function required, but not found

error: requires `sized` lang_item

For more information about this error, try `rustc --explain E0463`.
error: could not compile `post-build-script` (bin "post-build-script") due to 7 previous errors

We currently create an empty Cargo manifest for the post build script, so no dependencies are supported.

Running cargo post on a multi-package project tied together with a virtual manifest (a Cargo.toml with only [workspace] and members definitions in parent directory) panics with 'Please specify a --package argument'.

To reproduce

mkdir dummy
cd dummy
cargo new mine
cargo new --lib mylib

add the following Cargo.toml to dummy dir

[workspace]
members = ["mine","mylib"]

add the following to mine/Cargo.toml

[dependencies]
mylib = { path = "../mylib" }

run

cargo post --package mine

results in

thread 'main' panicked at 'Please specify a `--package` argument', /Users/<USERNAME>/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-post-0.1.3/src/main.rs:109:17

I've tried this on both stable and nightly.

It does work when you remove dummy/Cargo.toml, add [workspace]without any members definition to mine/Cargo.toml and run cargo from mine subdirectory. In that case there's obviously no need for the --package parameter.

If .config/cargo contains a build target where std is not available, post-build will fail, as it tries to compile post-build for said target.

.cargo/config:

[build]
target = "thumbv7em-none-eabihf" # Cortex-M4F and Cortex-M7F (with FPU)

post_build.rs:

use std::{path::PathBuf, env};

fn main() {
    let current_dir = env::current_dir().unwrap();
    let current_parent = current_dir.parent().unwrap();
    println!("current_dir: {:?}", current_dir);
    println!("current_parent: {:?}", current_parent);
    println!("ok");
}

cargo post build -p factbird-rs:

Finished dev [optimized + debuginfo] target(s) in 0.03s
Running Post Build Script at /home/mathias/git/blackbird/factbird-mini/factbird-rs/post_build.rs
   Compiling post-build-script v0.1.0 (/home/mathias/git/blackbird/factbird-mini/target/post_build_script_manifest)
error[E0463]: can't find crate for `std`
  |
  = note: the `thumbv7em-none-eabihf` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: could not compile `post-build-script`

To learn more, run the command again with --verbose.

I can't quite figure out if this is actually the same as #2 ?

As i see it, the post_build script should always be run using the host target, and never be influenced by .config/cargo target?

When I ran cargo post build -r (which is the same as --release) the environment variable CRATE_OUT_DIR was set to the target/debug folder rather than the target/release folder.

See #10. A pull request to fix this escaping problem would be appreciated!