search

nbp / holyjit

Generic purpose Just-In-time compiler for Rust.
https://holyjit.org/
Mozilla Public License 2.0
1.5k stars 26 forks source link

Distribution as cargo binary on a "stable" version #24

Closed siriux closed 6 years ago

siriux commented 6 years ago

First of all great work, the change to a rustc wrapper looks pretty cool and it seems easier to use (not tried yet).

But I've been thinking that a way to make it even easier for users would be to distribute it as a crates.io binary we can install with cargo install holyjit. Then, just providing the path on the rustc entry in the cargo.toml would be enough to use it.

Also, if the version on crates.io is the nightly equivalent of a stable version it can make things easier for users, and if you don't opt-in for any nightly features is the same as using stable.

Maybe we can even disable the nightly features on the driver code, and the nightly compiler would only be needed for the cargo install. In this case we would need two binaries in crates.io holyjit-stable and holyjit-nightly.

This would be perfect for users, as the installation and configuration is minimal and for all practical purposes they can use "stable" rust.

nbp commented 6 years ago

At the moment stabilizing is premature, as mentioned in https://github.com/nbp/holyjit/issues/23#issuecomment-373479796 .

HolyJit relies on a few features which are not yet stable, such as fn_traits to implement the jit! macro.

While I think moving HolyJit to stable might happen later, I do not think this would be of any help to the community to publish HolyJit on crates.io while it does not fully support rustc completely, and while it does not hold on its promise of providing a minimum of performance. (which is today even worse than the debug mode)

siriux commented 6 years ago

Sure, I was just thinking for the future, not something to do now as a priority.

In my opinion, for this to be successful it has to be used by multiple JIT projects, this way it can be improved and optimized fast. And for that to happen it has to be possible to integrate it seamlessly into stable projects.

That's why I wonder about this now, to evaluate if this new way of approaching Holyjit has this potential, or a new approach would be needed later. But of course, it's not needed until Holijit is more or less complete.

So it's good news to hear that moving it to stable might happen in the future.

Cheers