Open strahlc opened 7 years ago
I have forked and updated all versions if you want to give that a go:
https://github.com/aaronovz1/meta-nodejs/tree/pyro
Pull: #86
@imyller Can you pull this, please.
I used the fork https://github.com/aaronovz1/meta-nodejs/tree/pyro but had troubles running bitbake for version 8.9.4 (which is the latest LTS). I use arm7. There were several build errors, mostly in /nodejs/8.9.4-r1.1/node-v8.9.4/out/Release/obj/gen/src/inspector/protocol like "/build/tmp/work/cortexa9hf-vfp-neon-phytec-linux-gnueabi/nodejs/8.9.4-r1.1/node-v8.9.4/out/Release/obj/gen/src/inspector/protocol/Protocol.cpp:7: /usr/include/c++/5/bits/stl_algobase.h:59:28: fatal error: bits/c++config.h: No such file or directory compilation terminated." So I extended the recipes from 6.10.x to 8.9.4, which I added in a new fork. NPM@5.6.0 has changed, due to which, the no-registry_x.x.patch files have to be changed also, to include nodejs 8.9.4 in the final image. https://github.com/jmfNodejsUser/meta-nodejs/tree/patch-1/recipes-devtools/nodejs
Where is this issue at these days? And, will it be moved along to 8.10.0 now? I'm going to possibly embark on a move from v4.4.5 to v8.x.x shortly. So, this is an important one for me. BTW, is there someplace I can find things like memory and disk footprints of node versions in general? Just looking to see how big node proper has gotten over the years ...
I updated my fork to have 8.10.0 and 9.8. I'll probably update it to 8.11 and 9.10 in the coming weeks. As @jmfNodejsUser pointed out, my fork may not work for ARM builds (I don't develop for ARM) but I did incorporate the no-registry patches and can fix up further issues if someone wants to test on ARM.
We're on a Cortex-A7. Is there a node.js compliance test that can be run to help "verify" a build?
I'm not sure. I believe initially my fork will probably just throw compile-time errors if I've missed something for cross compiling for ARM.
Hi,
Is the project orphaned ? maybe it could be transferred to @abandonware org:
https://rzr.github.io/rzr-presentations/docs/abandonware
Then existing forks can be merged into a community maintained upstream project, until someone is aiming to adopt it for proper maintenance ?
Meanwhile maybe it's better to use OE as upstream:
https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-devtools/nodejs
see https://medium.com/the-node-js-collection/news-node-js-8-moves-into-long-term-support-and-node-js-9-becomes-the-new-current-release-line-74cf754a10a0 for details