Ancestors

Toot

Written by dorotaC on 2025-01-29 at 17:24

[#]cargo question.

Use case: the application is going to distributed with a couple extra files alongside.

Their final location will be in /usr/somewhere. Thy are generated in target/debug or target/release while developing.

How do I force cargo run to give the application the right path to the target dir?

[#]rustlang #programming #AskFedi #rust #coding

=> More informations about this toot | More toots from dcz@fosstodon.org

Descendants

Written by dorotaC on 2025-01-30 at 08:09

I think I know.

First, add code in your application to detect if running under cargo (so not installed). Maybe some env var.

Then find out executable's directory and navigate from there to where cargo stores the asset files.

It's a hack. Cargo should not get special treatment, in fact I already have an env var for "data location". But if it works, it's better than if it doesn't.

=> More informations about this toot | More toots from dcz@fosstodon.org

Written by Marc on 2025-01-29 at 17:37

@dcz not sure what you want exactly, you'd have a look on cargo install ?

=> More informations about this toot | More toots from corpsmoderne

Written by dorotaC on 2025-01-29 at 17:47

@corpsmoderne Thanks for the command, I didn't know it.

But it doesn't help, I want cargo run to work as if stuff was already installed.

=> More informations about this toot | More toots from dcz@fosstodon.org

Written by dorotaC on 2025-01-29 at 17:48

@corpsmoderne Oh, it's for installing things from a crates repository without using the OS package manager. That's why I never used it :D

=> More informations about this toot | More toots from dcz@fosstodon.org

Written by Marc on 2025-01-29 at 17:49

@dcz cargo install --path . installs your local project to somewhere on the system though...

=> More informations about this toot | More toots from corpsmoderne

Written by Marc on 2025-01-29 at 17:49

@dcz there's something I must miss :) if the application is already built, why call cargo and not directly the binary from ./target/release , or from anywhere else?

=> More informations about this toot | More toots from corpsmoderne

Written by dorotaC on 2025-01-29 at 17:50

@corpsmoderne Because the binary is not the entire application. I want the binary to know where the other files are: is it target/debug or target/release.

=> More informations about this toot | More toots from dcz@fosstodon.org

Written by Marc on 2025-01-29 at 17:51

@dcz ha yes, that's the part I've missed XD

=> More informations about this toot | More toots from corpsmoderne

Written by rillian on 2025-01-29 at 18:09

@dcz Maybe allow paths starting at CARGO_MANIFEST_DIR to override whatever PREFIX path you're expecting to use after install?

https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates

=> More informations about this toot | More toots from rillian@hachyderm.io

Written by dorotaC on 2025-01-29 at 18:27

@rillian Actually, OUT_DIR is what I'm looking for.

Maybe I can make this suck less, thanks!

=> More informations about this toot | More toots from dcz@fosstodon.org

Written by rillian on 2025-01-29 at 18:30

@dcz Oh, great. Is that set by cargo run as well as for build scripts?

=> More informations about this toot | More toots from rillian@hachyderm.io

Written by rillian on 2025-01-29 at 18:39

@dcz Looks like it isn't.

There is a std::env::current_exe() call which is a little less mysterious a place to start a relative-path hack than argv[0].

=> More informations about this toot | More toots from rillian@hachyderm.io

Written by dorotaC on 2025-01-29 at 18:54

@rillian Nooooo ;_; So close, yet so far.

I don't think current_exe helps much. The build path can be pretty arbitrary, and guessing based on debug in the path wold be rather inaccurate.

=> More informations about this toot | More toots from dcz@fosstodon.org

Written by rillian on 2025-01-29 at 18:29

@dcz If your data files really are generated in a way that depends on the build target, I don't know of a good way to access that. Maybe you could hack something looking at argv[0]?

I think your approach here is in philosophical opposition to rust's static linking model. In this situation I've always either used one of the include! macros to compile the data into the executable, or done something with environment variables and fallbacks to set a path to a config file.

=> More informations about this toot | More toots from rillian@hachyderm.io

Written by dorotaC on 2025-01-29 at 18:50

@rillian I don't think it has much to do with static linking, but rather the ability for an application to be built out of multiple pieces.

The file could be a plugin, or an asset, or a config file, and inlining those doesn't make sense.

Cargo is just a lousy build system.

=> More informations about this toot | More toots from dcz@fosstodon.org

Written by Kornel on 2025-01-29 at 19:46

@dcz Nope. Cargo does not support additional files in a sensible way.