Mac OS X (macOS) Support Roadmap
joshgarde opened this issue · comments
So a few months ago I got started on OS X build support for NodeOS, but I never really finished the effort. I've finally found the time to come back and revisit it.
Here's a summary of what currently works and what doesn't
- NodeOS (obviously)
-
- nodeos-cross-toolchain
-
- nodeos-barebones
-
- nodeos-bootfs
-
- nodeos-initramfs
-
- nodeos-userfs
Mac OS X is an odd beast to port over to, but progress will slowly be made. I'll report back with any updates. It's nice to be back here.
Current statuses:
-
nodeos-cross-toolchain
🎉 COMPLETE🎉
Full support is complete. -
nodeos-barebones
ON HOLD
Support has not yet been started. -
nodeos-bootfs
ON HOLD
Support has not yet been started. -
nodeos-initramfs
ON HOLD
Support has not yet been started. -
nodeos-userfs
STALLED
Node.js 7.x's cross compile support is not borked due to a new version of V8. An initial port attempt somewhat fixes Linux build support across gcc/musl systems, but OS X is a lost cause (for now).
Good to see you back :-) As I've said before I'm finishing a full refactor of NodeOS that will increase modularity and help in development, mainly changing the architecture to how it should have been from begining without legacy architectural decisions. Probably you'll need to change some things, but it will be the best for the future of the project :-)
By the way, both nodeos-cross-toolchain and nodeos-usersfs are mostly autonomous and frozen regarding the new architecture, so maybe you would be interested in take a look at them for the porting :-) I hope to have the others ready for this weekend :-)
Any updates on the refactor?
Any updates on the refactor?
It's almost done...
Prebuild images are being generated, but it was flaky because the partitions where hardcoded. I've been all the weekend fighting with libblkid because its code sucks, but finally I was able to get the dev path from the partition UUID, problem is that only when used as dynamic library and not compiled statically because the library is difficult to configure to be used with gyp, so it will be needed to bea added. Ugly, but if it works, it would be enough by now...
After that, the tests are not passing due to nsh and the Node.js bug regarding stdio redirection. I'm thinking about using a less strict test so they can pass and later focus on that problem, doing so probably I would be able to release it today or tomorrow, what do you think?
Take your time. I'm going to get started on porting over node-userfs in the meanwhile.
Just a quick question: Why are a lot of NodeOS packages using version numbers that are breaking builds? For example: https://github.com/NodeOS/nodejs
nodeos-cross-toolchain prebuild uploaded. Can I get permission to upload prebuilds for other repos?
nodeos-cross-toolchain prebuild uploaded. Can I get permission to upload prebuilds for other repos?
It's ok for me. Don't you have access to them too? We should need to see how to automate them too for OSX
No, I don't have access to the other repos. As for automation, I might just experiment with running OSX on traditional Linux VPSs for cheaper overall costs.
No, I don't have access to the other repos
Ok, I could be able to uploade them myself, or I could be able to give you access on request.
As for automation, I might just experiment with running OSX on traditional Linux VPSs for cheaper overall costs
I would stick with TravisCI, at least we can be able to do some checkings and do a basic build although other targets would be needed to be compiled by the users, the process is automated. If we need other targets too, we can be able to publish them by hand.
Can I get TravisCI enabled on qemu? Prebuilds should work there.
Can I get TravisCI enabled on qemu? Prebuilds should work there.
Well... it's already enabled, only that they are not being published. It should be easy, though...