Evertime I try and run something it seems to do a full rebuild?

[DanielJoyce]

Is this expected behavior?

pax-cli run -p space-game

[Pax] 🛠️  Building parser binary with `cargo`...

First it says its building the pax parser binary, it says the same thing for every other example. This step takes like 60s. Is this not being cached properly by pax-cli?

Also the spacegame example fails to run due to compiler errors

error[E0308]: mismatched types
    --> /home/XXXXXXX/git/general/pax/examples/src/space-game/.pax/pkg/pax-cartridge/src/lib.rs:1496:44
     |
1496 | ...                   cp.transform = resolved_property
     |                       ------------   ^^^^^^^^^^^^^^^^^ expected `Property<Option<Transform2D>>`, found `Property<Transform2D>`
     |                       |
     |                       expected due to the type of this binding

[DanielJoyce]

Okay, so the parser binary is per application?

[samuelselleck]

Thanks for letting us know!

The build times when running a project for the first time are not great at the moment, but they'll improve substantially soon once we rework our build system.

Currently master is pointing to a version of pax past the lastest pax-cli release. If you want to run it now you can go back to this commit: https://github.com/paxengine/pax/tree/90d69ed3e7caa29ff4659c96717ec1b540bb0c15. I'll also do a new release shortly, after which you should be able to run it after updating the pax-cli on master head.

[zackbrown]

Regarding compilation speeds, two concrete actions planned:

(1) Remove the need for the .pax folder + filesystem codegen. This requires a refactor of the dependency graph, allowing a userland crate to be a bin instead of a lib. Then, for a Pax #[main] component, move the logic for bootstrapping the engine from the chassis to the new macro-codegenned main() for that #[main] component (also offer a manual API for bootstrapping, see #[tokio::main] for inspiration.) After the bin is shifted to the userland crate, we can unpack all codegen at rustc compiletime (macro eval time) instead of temp .pax folder, and make a huge ergonomic leap forward in our build process.

(2) Refactor from dynamic to static analysis: the "parser binary" performs reflection for us, which we need for certain codegen (need to know the presence of and types of Property<T>s, among other things.) When I built this v0, there was no apparent off-the-shelf reflection solution for Rust, so I hacked this together. It's slow, requiring at least 2x compilation and some duct-taped serialization. A better solution would be static analysis — essentially do a light subset of what rust-analyzer does to solve our reflection requirements.

[zackbrown]

and make a huge ergonomic leap forward in our build process.

Missed an important point: this unlocks cargo run instead of pax-cli run

[DanielJoyce]

Bevy has a compile time reflection which may be a fit.

https://docs.rs/bevy_reflect/latest/bevy_reflect/

[zackbrown]

Now that Pax has hot module reloading (via Pax Designer — you can try it by following the Get Started instructions) I believe the core issue here is resolved — you can now make ~instantaneous changes to Pax files without rebuilding.

We have also removed the need for most of the .pax folder contortions described in my last comment, and we've sped up full build times substantially through profile tuning. Though build times are getting to a pretty good spot, static analysis will still be a major future upgrade, completely removing the need for the parser binary phase and cutting full build times by ~half.