libdeno and DenoCore to Deno.core #1998
Conversation
|
@ry @piscisaureus it seems that at the stage the build tries to compile core on Windows the I am not familiar enough with it to understand what is going wrong here. Any thoughts? |
51ce47d
to
b98418f
Compare
|
@kitsonk Nice! It seems there's also a failure in the travis cargo build, with the same GN_OUT_DIR error. This suggests to me (tho I'm not sure) that it's because the build.rs file isn't being applied to the core crate. |
|
Why don't we do the renaming of stuff but hold off on the |
|
@kitsonk Sounds good. I think I'm going to reorganize the tree here in a bit so the "core" is the main crate and "cli" is the child crate. I think that will take care of the GN_OUT_DIR problem - but it will take me a bit before I can get there. |
|
Ok, it is removed. Strangely the |
|
@ry I think the Appveyor failure is not related to this PR and something transitory. It is passing everywhere else. 🤷♂️ |
| @@ -614,15 +614,15 @@ mod tests { | |||
| } | |||
|
|
|||
| #[test] | |||
| fn test_dispatch() { | |||
| fn testdispatch() { | |||
| // TODO(ry) This test is quite slow due to memcpy-ing 100MB into JS. We | ||
| // should optimize this. | ||
| let mut isolate = TestBehavior::setup(TestBehaviorMode::OverflowResAsync); | ||
| js_check(isolate.execute( | ||
| "overflow_res_multiple_dispatch_async.js", | ||
| "overflow_res_multipledispatch_async.js", | ||
| r#" |
Resolves #1956
This PR migrates the
libdenonamespace and theDenoCorenamepsace toDeno.core. Also all the properties ofDeno.coreare prefaced with_and not included in the runtime type library, as they are not intended for end user use and internal to Deno only.This also converts the/core/*.jsfiles to.tsand builds them.