search

bytecodealliance / cranelift

Cranelift code generator
https://cranelift.readthedocs.io/
2.49k stars 202 forks source link

Delete all code to invalidate existing PRs #1414

Closed alexcrichton closed 4 years ago

alexcrichton commented 4 years ago

Also leave a note in the README that the project has moved

redradist commented 4 years ago

@alexcrichton

One question ... Why Cranelift was moved in wasmtime ?

Seems like Cranelift could be used not only for wasm target, but also as native compiler and so on

bjorn3 commented 4 years ago

I think the reason was to make it easier to coordinate changes that affect both Cranelift and Wasmtime. Cranelift can indeed be used for purposes other than wasm compilation.

redradist commented 4 years ago

@bjorn3

I think the reason was to make it easier to coordinate changes that affect both Cranelift and Wasmtime. Cranelift can indeed be used for purposes other than wasm compilation.

But it makes hard for other projects to integrate it as submodule !! If I want only cranelift and do not want wasmtime at all, I use only x86_64 code generation ... ?!

bjorn3 commented 4 years ago

Just include the whole Wasmtime repo. For path dependencies, you have to use wasmtime/cranelift/codegen. For git dependencies cargo will search for crates in every directory: https://github.com/bjorn3/rustc_codegen_cranelift/blob/9c0d18c8db1e60343f61641a71d8b69bb1ad6233/Cargo.toml#L12-L15.

redradist commented 4 years ago

@bjorn3

Just include the whole Wasmtime repo. For path dependencies, you have to use wasmtime/cranelift/codegen. For git dependencies cargo will search for crates in every directory: https://github.com/bjorn3/rustc_codegen_cranelift/blob/9c0d18c8db1e60343f61641a71d8b69bb1ad6233/Cargo.toml#L12-L15.

And then what ? If one day wasmtime become part of other project ? I would need to include whole some_other_project/wasmtime/cranelift ?

Seems like it was done for persons that cannot use git submodule update --recursive command ((

tschneidereit commented 4 years ago

@redradist please don't jump to conclusions quite this quickly, in particular if they involve assuming that we're all somehow incompetent.

We had good reasons to do this, see [my comment here for background].(https://github.com/bytecodealliance/wasmtime/issues/1185#issuecomment-591050388)

(Note also that compiling Wasmtime still requires the exact git submodule handling you mention.)

redradist commented 4 years ago

@tschneidereit

@redradist please don't jump to conclusions quite this quickly, in particular if they involve assuming that we're all somehow incompetent.

We had good reasons to do this, see [my comment here for background].(bytecodealliance/wasmtime#1185 (comment))

(Note also that compiling Wasmtime still requires the exact git submodule handling you mention.)

But according that I have read from this comment, it would be better to rename wasmtime to bytecode vm (like LLVM) or bytecode toolchain or other fancy name and make wasmtime as sub-project:

bytecode_vm
  |_
    \_ cranelift
  |_
    \_ wasmtime

It would make more sense ...

tschneidereit commented 4 years ago

But according that I have read from this comment, it would be better to rename wasmtime to bytecode vm (like LLVM) or bytecode toolchain or other fancy name and make wasmtime as sub-project

I guess I'll just note your opinion on this. I disagree with it, but I also don't think it makes sense to continue this discussion, and hope that you don't expect us to go and change everything based on the argument you gave. A lot of thought and discussion has gone into this decision, and I'd once again kindly ask you to consider that there might be more to it than seems immediately intuitive to you.

redradist commented 4 years ago

@tschneidereit

But according that I have read from this comment, it would be better to rename wasmtime to bytecode vm (like LLVM) or bytecode toolchain or other fancy name and make wasmtime as sub-project

I guess I'll just note your opinion on this. I disagree with it, but I also don't think it makes sense to continue this discussion, and hope that you don't expect us to go and change everything based on the argument you gave. A lot of thought and discussion has gone into this decision, and I'd once again kindly ask you to consider that there might be more to it than seems immediately intuitive to you.

It was just suggestion that will clear little bit why for example somebody integrates whole wasmtime, if it would named as I suggest, it would be clear that submodule is just toolchain ...

But anyway it was suggestion, thank for clarifying your decision point ;)