Remove platform rebuilding and generate_stub_lib

[lukewilliamboswell]

zulip discussion

This PR

• removes the generate_stub_lib
• removes rebuilding host functionality from the roc cli
• modifies roc preprocess-host

Roc platform hosts' are responsible for building using their native toolchain so they provide the binaries for legacy and surgical linking. The roc cli no longer has any dependency on a host toolchain.

The API for pre-processing the host has changed to the following:

$ cargo run -- preprocess-host --help
    Finished dev [unoptimized + debuginfo] target(s) in 0.31s
     Running `target/debug/roc preprocess-host --help`
Runs the surgical linker pre-processor to generate `.rh` and `.rm` files.

Usage: roc preprocess-host [OPTIONS] <host> <platform> <lib>

Arguments:
  <host>      Path to the host executable where the app was linked dynamically
  <platform>  Path to the platform/main.roc file
  <lib>       Path to a stubbed app dynamic library (e.g. roc build --lib app.roc)

Options:
      --target <target>  Choose a different target [default: macos-arm64] [possible values: linux-x32, linux-x64, linux-arm64, macos-x64, macos-arm64, windows-x32, windows-x64, windows-arm64, wasm32]
      --verbose          Print detailed information while pre-processing host
  -h, --help             Print help

[bhansconnect]

I think we should really change the ux here as part of this change.

I am also really not a fan of requiring platforms to include some sort of special libapp.roc and dynhost just to enable correctly linking. These are the types of confusing implicit deps that make it hard to use.

Like, probably can just be:

roc build --lib examples/simple.roc
cargo build
roc preprocess-host --host target/build/host --platform platform/main.roc

If we want/need to still depend on the dylib, lets make it explicit instead of locking in on libapp.so that happens to be in the platform directory.

roc build --lib examples/simple.roc
cargo build
roc preprocess-host --host target/build/host --platform platform/main.roc --lib examples/simple.dylib

Fundamentally, the libapp and dynhost naming should die. It is just a weird constraint that will confuse users, especially if it is implicit like this.

---

I also am questioning if it would be possible to just use an example as the actual input. The example once parsed knows where the platform is. If the example is example/simple.roc, the dylib should be example/simple.dylib. I guess that still leave an open question about host binary though.

---

All this said, I think we can remove the dependency on an actual dylib and the stub symbols. So I think we should remove both of those. The only piece of information we actually need is what shared library the host thinks it linked to such that we can remove that dependency during preprocessing.

So I guess, I currently lean most towards this api if it works:

roc build --lib examples/simple.roc
cargo build
roc preprocess-host --host target/build/host --app examples/simple.roc

[lukewilliamboswell]

Current progress for cargo test -p roc_cli

failures:
    cli_run::hello_gui
    cli_run::inspect_gui
    cli_run::known_type_error
    cli_run::platform_switching_main
    cli_run::platform_switching_rust
    cli_run::platform_switching_swift
    cli_run::platform_switching_zig
    cli_run::ruby_interop
    cli_run::static_site_gen
    cli_run::swift_ui
    cli_run::terminal_ui_tea

test result: FAILED. 46 passed; 11 failed; 1 ignored; 0 measured; 0 filtered out; finished in 30.70s

error: test failed, to rerun pass `-p roc_cli --test cli_run`

[Anton-4]

Task is used very heavily here, I'd be in favor of going with import pf.Task as T.

[Anton-4]

We should make functions for these in basic-cli, that will clean things up roc-lang/basic-cli#203.

[Anton-4]

This looks good to me in general :)

[lukewilliamboswell]

@Anton-4 -- do you think we should try and keep both breakout and the gui platform? They aren't in a good state currently. I have made changes so they at least compile and are usable (though breakout I have basically broken entirely) for CI purposes. What is our plan/thoughts longer term?

[Anton-4]

Yeah, let's take them out, I don't think they've been a net positive overall.

[lukewilliamboswell]

TODO - move to a better location than in examples