Gered
c7d6bd8aef
ultimately, cargo workspaces are kind of weird. you can do things like `cargo run` from the top-level cargo.toml file and run an individual sub-module via `--bin`, or you can go to that sub-module's directory where it's own cargo.toml is, and `cargo run` directly from there. the current working directory will be different in each case, and this difference can be very annoying when you want to do seemingly-logical things like organize sub-module "asset" files (e.g. images, and other types of data files that aren't code) within that sub-module's directory. in this case, how do you write code in that sub-module that can load those asset files in a way that will work in BOTH of the aforementioned scenarios for `cargo run`? you can't really! some people use the `CARGO_MANIFEST_DIR` environment variable that cargo sets when running any given cargo module, but this is only a valid method for obtaining the module's root directory when running from a cargo command ... which you won't be doing when running within a debugger! likely you or your IDE invoked the debugger process against the already built executable directly, so `CARGO_MANIFEST_DIR` will not be set and you're back to square one! super annoying! as such, i am now giving up and am just doing what it seems like most other cargo projects that utilize workspaces do ... place all the assets for all sub-modules together in the same directory, relative to the workspace root. why go with this approach? because it works under the most common scenarios (but NOT all!): - running via `cargo run --bin` from the workspace root - debugging via gdb/lldb etc using the workspace root as the cwd these seem to be the most common ways to do each type of task from any rust-equipped editor/IDE that i've seen so far.
22 KiB
22 KiB