-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Packaging up js-quic for Linux, Windows, MacOS #7
Comments
Nothing on mobile just yet... but that will be important in the future. Mobile usage is complicated by the fact that the same code will need to compile to target the mobile platforms, and the bindings won't be napi-rs since it's not an Node API, instead native modules like in React would need to be used. |
Will temporarily rebase and squash the master branch later in order to clean up the history too. |
@tegefaulkes to track this. |
The codesee maps is integrated into this https://app.codesee.io/maps/c108c990-f46b-11ed-ad69-ede85191d1b1. Gitlab pull mirroring isn't working, so this requires manual pushes atm.
|
History has been squashed... and reset. Both staging and master is now on the same commits. @tegefaulkes can you try to rebuild/re-run any tests to see I didn't screw it up. Just clone the repo to a new directory before trying anything, then if it is all good you can delete both repos and just clone from the new repo. |
Currently CI/CD is failing... need to investigate why. I haven't reviewed any of the tests or whether the code is linted or not, and I don't know if mac/windows build scripts will work. These will need to be debugged on our local systems in office. |
just ran the tests, I'm getting the following. [nix-shell:~/matixWorkspace/gitRepos/js-quic]$ npm run test
> @matrixai/[email protected] test
> jest
Determining test suites to run...
GLOBAL SETUP
PASS tests/utils.test.ts (6.647 s)
utils
✓ detect IPv4 mapped IPv6 addresses (24 ms)
✓ detect IPv4 mapped IPv6 Dec addresses (9 ms)
✓ detect IPv4 mapped IPv6 Hex addresses (12 ms)
✓ to IPv4 mapped IPv6 addresses Dec (1 ms)
✓ to IPv4 mapped IPv6 addresses Hex (3 ms)
✓ from IPv4 mapped IPv6 addresses (3 ms)
✓ to canonical IP address (4 ms)
✓ resolves zero IP to local IP (4 ms)
FAIL tests/QUICSocket.test.ts
● Test suite failed to run
Failed requiring possible native bindings: quic-linux-x64.node,@matrixai/quic-linux-x64
73 | }
74 | }
> 75 | throw new Error(
| ^
76 | `Failed requiring possible native bindings: ${prebuildTargets.concat(npmTargets)}`
77 | );
78 | }
at requireBinding (src/native/quiche.ts:75:9)
at Object.<anonymous> (src/native/quiche.ts:117:25)
at Object.<anonymous> (src/native/index.ts:1:1)
FAIL tests/QUICClient.test.ts
● Test suite failed to run
Failed requiring possible native bindings: quic-linux-x64.node,@matrixai/quic-linux-x64
73 | }
74 | }
> 75 | throw new Error(
| ^
76 | `Failed requiring possible native bindings: ${prebuildTargets.concat(npmTargets)}`
77 | );
78 | }
at requireBinding (src/native/quiche.ts:75:9)
at Object.<anonymous> (src/native/quiche.ts:117:25)
at Object.<anonymous> (src/native/index.ts:1:1)
FAIL tests/QUICStream.test.ts
● Test suite failed to run
Failed requiring possible native bindings: quic-linux-x64.node,@matrixai/quic-linux-x64
73 | }
74 | }
> 75 | throw new Error(
| ^
76 | `Failed requiring possible native bindings: ${prebuildTargets.concat(npmTargets)}`
77 | );
78 | }
at requireBinding (src/native/quiche.ts:75:9)
at Object.<anonymous> (src/native/quiche.ts:117:25)
at Object.<anonymous> (src/native/index.ts:1:1)
FAIL tests/concurrency.test.ts
● Test suite failed to run
Failed requiring possible native bindings: quic-linux-x64.node,@matrixai/quic-linux-x64
73 | }
74 | }
> 75 | throw new Error(
| ^
76 | `Failed requiring possible native bindings: ${prebuildTargets.concat(npmTargets)}`
77 | );
78 | }
at requireBinding (src/native/quiche.ts:75:9)
at Object.<anonymous> (src/native/quiche.ts:117:25)
at Object.<anonymous> (src/native/index.ts:1:1)
Test Suites: 4 failed, 1 passed, 5 total
Tests: 8 passed, 8 total
Snapshots: 0 total
Time: 7.267 s, estimated 35 s
Ran all test suites.
GLOBAL TEARDOWN |
That's cause you need to build it now |
Some of your stream tests are really slow btw. We need to review all tests and make them pass. I've just run them too and I get:
|
One of the problems with using brew is that it doesn't always have exact versions. In the case of rust we only have just |
Looks like I also need:
For the windows compilation. Even though it is not necessary in Linux. Bringing that into Chocolatey requires llvm. Furthermore the |
For windows I'm now hitting this problem: cloudflare/boring#121. Not sure how to proceed here for now. It appears to work on their Github actions, but they are using an older llvm. I may need to try version 11. Also using |
For macos, it appears that we actually need to build separately the arm64 and x64, then use the I think this can be done by running the prebuild script twice... and using universal to combine them. |
Regarding macos, I'm testing on the local system now. It appears that arm64 macos requires an additional thing to be able to cross compile for A message pops up saying:
This might also be needed on the macos machines on gitlab too. The need to add additional targets. |
Ok it appears that the command
This command is part of xcode. I could skip using |
Actually this
At least it will end up being quite specific. So on arm64, load the arm64 version, on the x64, load the x64 version. |
Seems like Right now specific rust versions is not necessary, but cmake is still necessary. |
We should have a working linux and macos build. Windows will depend on cloudflare/boring#121 |
There's an existing rust installation already on the gitlab macos.
If we use |
There's a script that
But it seems to be appending the path instead of prepending the path. |
Apparently the MacOS will only be for premium: https://gitlab.com/gitlab-com/runner-saas-macos-access-requests/-/issues/233#note_1394334519 Will probably have to upgrade soon enough. We may need to switch up the tags to |
MacOS builds are succeeding: @tegefaulkes tests are failing though, some tests take WAY too long, you need to split it up or optimise it. See pipeline test timeouts: https://gitlab.com/MatrixAI/open-source/js-quic/-/pipelines on macos job and occasionally on linux job too. Also you probably want to clean up your logging messages too, it's a bit ugly. |
I'm aware that rust also is capable of full cross compilation directly from Linux. I should explore this later, because that could simplify things in the CI/CD system. |
If this could work... it might be better to move all native packages to using rust instead of the old node-gyp system which is overly complicated. |
The CI/CD is all tested. The windows build is no go for now. Not important, will track that for a later issue. The only thing left is for @tegefaulkes to clean up the tests, and then test out the version scripts and the prepublish scripts. We'll leave that until the tests are done and 0.0.1 is being published. Will close this issue for now. |
Specification
As js-quic is a native package, it has much more complicated packaging procedure making it similar to js-db. However this is different because it uses Rust instead of C++, therefore the entire toolchain is different from js-db.
Rather than
tsc
,node
,node-gyp
,napi-macros
andnode-gyp-build
. This is justtsc
,node
andnapi-rs
.What needs to be done is:
neon
. For example theneon-cli
package is no longer needed andcargo-cp-artifact
is also not required.napi-macros
andnode-addon-api
andnode-gyp
. All of these packages and related configuration is no longer needed. This includes removingnode-gyp-build
too.napi-rs
and the related rust and cargo tools are brought in from theshell.nix
.threads
.npm run napi-build
andnpm run napi-build-prod
should be integrated into thenpm run prebuild
script located insrc/scripts/prebuild.js
.prebuild.js
was ported fromjs-db
which usesnode-gyp
. This does not usenode-gyp
at all, and instead needs to usenapi build
command instead. All relevant flags and options should be adapted tonapi build
which comes from the@napi-rs/cli
package.prebuild.js
is be able to build binaries and put them into aprebuild
directory. This directory is packaged as part of the npm distribution, and so binary compiled artifacts are "prebuilt" before they are downloaded by downstream users. We should maintain this structure.napi build
ends up putting the artifact intoquic.linux-x64-gnu.node
on the project root. This should be put into the equivalent prebuild directories that js-db does.prebuild
directories... we might recover the ability to usenode-gyp-build
to look it up. But right now all that logic is written intosrc/native/quiche.ts
. Alternatively we give up onnode-gyp-build
entirely and just use our own script to find the right bindings.Note that on MacOS and Windows we are using homebrew and chocolatey respectively. This means the rust toolchain would come from those 2 areas instead of Nix. No way to use Nix on MacOS just yet, so it's just a good idea to ensure that we are in fact building with the same Rust version.
Additional context
napi
.Tasks
neon
. For example theneon-cli
package is no longer needed andcargo-cp-artifact
is also not required.napi-macros
andnode-addon-api
andnode-gyp
. All of these packages and related configuration is no longer needed. This includes removingnode-gyp-build
too.napi-rs
and the related rust and cargo tools are brought in from theshell.nix
.threads
.npm run napi-build
andnpm run napi-build-prod
should be integrated into thenpm run prebuild
script located insrc/scripts/prebuild.js
.prebuild.js
was ported fromjs-db
which usesnode-gyp
. This does not usenode-gyp
at all, and instead needs to usenapi build
command instead. All relevant flags and options should be adapted tonapi build
which comes from the@napi-rs/cli
package.prebuild.js
is be able to build binaries and put them into aprebuild
directory. This directory is packaged as part of the npm distribution, and so binary compiled artifacts are "prebuilt" before they are downloaded by downstream users. We should maintain this structure.napi build
ends up putting the artifact intoquic.linux-x64-gnu.node
on the project root. This should be put into the equivalent prebuild directories that js-db does.prebuild
directories... we might recover the ability to usenode-gyp-build
to look it up. But right now all that logic is written intosrc/native/quiche.ts
. Alternatively we give up onnode-gyp-build
entirely and just use our own script to find the right bindings.The text was updated successfully, but these errors were encountered: