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