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. |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
| screenshot.png | ||
ggdt - 'Flying Balls' Demo v2
Extension of the original 'Flying Balls' demo found in this repository under /examples/balls. This one is re-done
with some more effects, but with the major difference being utilization of the entity, events, and states support from
ggdt.
Simply do cargo run from this directory to try it out.
