Respect Cargo target directory configuration

[tyoeer]

Changes:

• Removes hard-coded target/server and target/front
  • Using the normal target directory allows for sharing build dependencies between projects, which can significantly reduce compile times
  • It is unclear why they're hardcoded separate directories in the first place
  • Removing them was easier than making them use the proper target directory
• Uses proper relative paths for bin and lib packages
  • Fixes a crash/panic when the configured target directory was outside the workspace directory
    • Fixes #74
    • Fixes #127
    • Fixes #157
    • Fixes #186
  • Adds dependency pathdiff
    • It can still fail, but insofar I can tell will only do so if the base path is relative and the target path is absolute
  • Absolute paths would be better:
    • No chance of failure
    • No additional dependency
    • But those break snapshot testing
• Defaults site-root to the /site/ subfolder of the cargo target directory
  • That is insofar I can tell how it was intended
  • The current method is a bit clunky, but it's the best I could come up with with serde's default
    • An alternative would be to use an option and set it to Some in parse(), but that would forces Some checks everywhere.
  • Snapshot testing survives this because the test cases always manually specify it.

Didn't manage to add additional regression tests:

• Changing the target directory has to be done through a .cargo/config.toml from where cargo is invoked, and does not take the --manifest-path into account
  • Known problem: https://github.com/rust-lang/cargo/issues/10098
• The tests already specify a cwd, though it'sn't used for the cargo metadata call, and isn't set to the directory of the actual project/workspace being tested. I can't figure out what exactly it's supposed to do, and I don't feel confident doing something with it.

Additional notes/things to look at that are outside the scope of this PR:

• Snapshot testing is broken for developers who have a different Cargo target directory
• clippy has complaints about cloning double references in src/ext/path.rs

[tyoeer]

Had to temporarily remove my own target-dir configuration to make it match the CI, but the tests look like they should match what the CI is expecting now.

[tyoeer]

As a general comment, could you please include a sample dev experience walkthrough of how to leverage these improvements? This way I don't have to guess if I did the right set up to verify changes are doing what they are intended to accomplish.

@aperepel The easiest way to test everything would be to configure the target directory in the top-level cargo configuration in ~/.cargo/config.toml, for example with:

[build]
target-dir = ".cargo/targetShare"

This shares the target directory between projects. I personally do this to speed up compilation and save disk-usage by re-using already compiled dependencies (between projects), other people might have other reasons.

With this configuration, one would expect that:

• No panics happen
  • Previously it would panic for target directories outside of the workspace (see linked issues)
• By default, the server binary gets built in the configured target directory, and can reuse compiled dependencies
  • This is configurable, though previously it would default to target/server, irregardless of the configured target directory, effectually overwriting your config for no apparent reason.
• The wasm/client binary gets built in the configured target directory (though in the wasm32-unknown-unknown subfolder), and can reuse compiled dependencies
  • Previously, this was hard-coded to target/front, with no way to configure/change it, , effectually overwriting your target directory config for no apparent reason.
• By default, the other site assets are put somewhere in the configured target folder
  • Previously, this would default to target/site, irregardless of the configured target directory, effectually overwriting your config for no apparent reason.

(Ideally there'd be a test demonstrating all this, but see my original PR comment for why I didn't manage to make one)

[Maneren]

Hello, what's the status here? I've been using a binary compiled from this PR for quite some time now (without any issues) and I'd love to see this merged so I can use other updates as well. Is there anything I can help with? (code, testing, review, ...)

[gbj]

Sorry for the delay here — I've been reviewing PRs post-0.5 and am going to start going through these now.

[Maneren]

No worries, thank you