Add prebuilds #992
Add prebuilds #992
Conversation
chearon
force-pushed
the
prebuild
branch
2 times, most recently
from
6ee7458
to
34630b5
Compare
|
(Would be nifty to setup a release hook that kicks off the prebuild process sometime.) Does the readme need to be updated to say something like "prebuilt will be used by default; if you want to build from source, use |
Definitely, I might have to set something up that builds the latest version if triggered from a URL. Then just add a web hook to automattic/node-canvas. The environment variables are useful for going back and updating binaries for old versions (e.g. node 9 released). I'll update the readme. |
|
🙌 Awesome, would you mind writing down some quick notes on how the releases process works? I created a |
|
Sure! I'll document it in a wiki. I'm okay with moving the repo as long as GH redirects old release tarball links correctly. I'm going to test that out now. If it doesn't, I'll have to fork a new repo to |
|
Great :) I added both you and @zbjornson as owners, I'd be happy to add anyone one else that's been contributing to node-canvas as well! Also, I just made the name up on the spot, if anyone have some better ideas we could of course roll with that 🙌 |
|
It works! Good on you, GitHub. I'm moving it now and then I'll update the PR. |
Good idea! If we end up with pluggable encoders/decoders (e.g. WebP and anything else beyond the Canvas spec requirements), that could be a good place to put them as well. (Could even be a new home for node-canvas if no one at automattic wants to "own" this repo anymore and deal with admin stuff like authorizing appveyor.) |
|
Finally created a wiki here to document the release process. If we were to start using this repo to build releases, you could ignore the Releasing to NPM section. Let me know if anything is unclear, I think I covered everything. |
|
@LinusU are you cool with merging this? :) |
|
Absolutely 👍 🚀 🎉 |
|
Published as |
|
Can this allow to move forward to static builds? I'm busy lately, but can be able to upgrade my pull-requests if needed... |
|
Static builds might still be a good idea to avoid issues like node-gfx/node-canvas-prebuilt#30 and #930. I think I've convinced myself that the node-canvas repo should build against system libraries, though, because that + Gyp (CMake in the future?) gives end-users a standardized, easier to understand build. |
|
Yeah, static builds are nice 👍 Personally, I'm super interested in shipping the entire module as a |
Yeah, and also the problems regarding to OSX and Windows builds due the need to install libraries and so.
That would be freaking cool! :-D I'm also looking about distribution of Node.js compiled modules as wasm files, no need of build environment for the |
|
Heh, we're all dreaming of no native dependencies. Someone made an implementation of Canvas in pure JS but without GPU it's just not practical. If Node gave us a way to communicate with the GPU someone could compile Cairo to WASM. HarfBuzz (font shaping) is already probably not that hard to compile to WASM, but then you have to do FreeType (glyph rendering) too and something for font selection, which could be done in JS since I think the spec is loose on that.
That would be cool, but how do we know the system has the library or has the right version? Isn't it just offloading the problem from build to runtime? |
Not directly, although you could probably expose
Is Cairo GPU accelerated? I didn't think it was 🤔 I think that WebGL integration is planned for WASM, but that is probably quite a while away, and it's also not clear if Node.js would choose to have that support... But if Cairo is just running on the CPU, we probably would be able to get comparable speeds with pure WASM. |
It isn't by default, but can use OpenGL. #909 intends to add some x86 intrinsics that WASM doesn't support, btw. My main issue with static builds is that they increase memory usage and occupy more of the CPU cache when the module is loaded by multiple node.js processes -- common because of node's native |
Very good point 👍 |
I don't think so, JIT can greatly improve performance, so for headless code I find it a good alternative. GPU would improve performance, but I don't find it something needed except for intensive calculations or drawing to an screen.
Node.js bindings for
I think this already is happening on load (aka. runtime) time with dynamic libraries...
That would be a cool project :-) Sort of like FFI, but having WASM just only floats and integers, it would be fairly easier.
Maybe just only optionally for graphic backends, not for in-memory rendering... Or use the GPU and later fetch the rendered image... Definitely I don't think it's working by default but instead is an opt-in, so probably we are not using it.
If they add WebGL support it would be API level, not in the core, so Node.js will not have anything of this and would need to be done in an external module.
I think so.
That's not really a problem because the operating system already have the compiled modules in the cache, so the only situation where it would be duplicated it's if you are using statically linked
Yes, that has been my idea from the begin, that static linking would only be done when dynamic libraries are not installed on the system or when enabled explicitly by hand. |
This is at least a first step towards fixing xtermjs#1247. This adds some complexity to the initial setup, since canvas needs to be built from source. This won't be true once canvas 2.x is stabilized, because that version downloads (Automattic/node-canvas#992). JSDom doesn't support 2.x, and doesn't until a stable release is cut. We could use [canvas-prebuilt](https://github.com/node-gfx/node-canvas-prebuilt), which JSDom does appear to support. However, I'm not sure if that would cause pain for people with 32-bit operating systems (see the compatibility table on that page). I'm not sure if this travis configuration will work; I'll iterate on it in the PR if it fails. I removed a bunch of hacks that were added in xtermjs#690, since they don't look necessary anymore (the sleep module is gone).
This is at least a first step towards fixing xtermjs#1247. This adds some complexity to the initial setup, since canvas needs to be built from source. This won't be true once canvas 2.x is stabilized, because that version downloads (Automattic/node-canvas#992). JSDom doesn't support 2.x, and doesn't plan to (jsdom/jsdom#1964) until a stable release is cut. We could use [canvas-prebuilt](https://github.com/node-gfx/node-canvas-prebuilt), which JSDom does appear to support. However, I'm not sure if that would cause pain for people with 32-bit operating systems (see the compatibility table on that page). I'm not sure if this travis configuration will work; I'll iterate on it in the PR if it fails. I removed a bunch of hacks that were added in xtermjs#690, since they don't look necessary anymore (the sleep module is gone).
This is at least a first step towards fixing xtermjs#1247. This adds some complexity to the initial setup, since canvas needs to be built from source. This won't be true once canvas 2.x is stabilized, because that version downloads (Automattic/node-canvas#992). JSDom doesn't support 2.x, and doesn't plan to (jsdom/jsdom#1964) until a stable release is cut. We could use [canvas-prebuilt](https://github.com/node-gfx/node-canvas-prebuilt), which JSDom does appear to support. However, I'm not sure if that would cause pain for people with 32-bit operating systems (see the compatibility table on that page). I'm not sure if this travis configuration will work; I'll iterate on it in the PR if it fails. I removed a bunch of hacks that were added in xtermjs#690, since they don't look necessary anymore (the sleep module is gone).
canvas-prebuilthas been working for a year now, and the latest version of the Linux build has broad compatibility. This would try to download the binaries from the prebuilt repo beforenode-gypand hopefully cut down on a lot of installation issues.You can check out this branch and
npm installto try it out.If we do go forward with this I can give access to @LinusU and @zbjornson and maybe others to the prebuilt repo, and document the release process better. It basically involves setting environment variables to indicate which version you want to build and release, and then you re-build the latest commit on AppVeyor/Travis.
(We could also use
prebuild-install, it has half the dependencies which is nice. But (1)node-pre-gypis more popular and thus more likely to already be installed and (2)prebuild-installis not compatible withcanvas-prebuilt's tarball structure (fixable for later versions)).edit:
Forgot this affects CI too, will fix that soonfixed,but CI is stalled nowCI fixed