Closed alexcrichton closed 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
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.
@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 ... ?!
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.
@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 ((
@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.)
@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 ...
But according that I have read from this comment, it would be better to rename
wasmtime
tobytecode vm
(like LLVM) orbytecode toolchain
or other fancy name and makewasmtime
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.
@tschneidereit
But according that I have read from this comment, it would be better to rename
wasmtime
tobytecode vm
(like LLVM) orbytecode toolchain
or other fancy name and makewasmtime
as sub-projectI 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 ;)
Also leave a note in the README that the project has moved