Chakracore: [Discussion] Linux / Cross-platform planning

[dilijev]

This is for general discussions on the cross-platfrom effort. Please open individual issues for tasks clearly identified from this discussion, or PRs if they are small and you can do them quickly.

Please see the Roadmap for our cross-platform checklist and progress.

Related issues:

• [ ] #197
• [ ] #198
• [ ] #200

See https://github.com/caitp/ChakraCore/issues/1 for some examples of work items we might want to consider.

[gabereiser]

personally, I prefer cmake chains but yeah, getting away from .sln msbuild is priority for me at least. Then we can #define our way through the headers to get it built for linux/osx. it shouldn't be that hard, just need to work around the windows.h stuff and maybe a redef here and there.

[digitalinfinity]

Hi @gabereiser- yup, cmake chain is what we're going for. We need the sln stuff for Windows too for some other reasons so we'll have to maintain parallel build definitions. We're doing this incrementally but check out the Linux branch for what we have so far. Cc @jianchun

[obastemur]

@digitalinfinity It will be eventually gypified for node.js build system integration right? Hope this question is not a total none-sense but why separate effort for cmake ? (I'm not arguing CMAKE vs GYP)

I already started to prepare that to integrate it into JXcore. Besides, once it works for Windows (quite) the same script will be very helpful on my effort to port Chakra to OSX/iOS.

[obastemur]

GYP is how you can build C/C++ libs for node.js, to run in V8.

@gabereiser You are mixing it with node-gyp. Wikipedia -> https://en.wikipedia.org/wiki/GYP_%28software%29

[gabereiser]

@obastemur indeed I am, nevermind then...

[leeter]

just curious what --std= will the port be targeting? I'm assuming --std=C++14? since that's actually complete with clang on 15.10

[deluxor]

I hope to see it compiled for ARM running as the core of nodejs on a linux machine :+1:

[dilijev]

@deluxor It's definitely a good goal to try to get ARM tests running on linux devices. Our CI doesn't run ARM tests (only builds) since the build machines are all Intel Windows machines. Internally we run ARM tests, but still it would be nice to get some ARM testing visible to the public.

[ariya]

I saw that CoreCLR's PAL code is being reused in pal/. I am curious if the plan is to import PAL wholesale or to pick only the necessary parts? I am inclined to think it is the latter, but I want to confirm my understanding.

[jianchun]

@ariya It is the latter. We are picking only what we need and probably will make necessary changes.

[jianchun]

just curious what --std= will the port be targeting? I'm assuming --std=C++14? since that's actually complete with clang on 15.10

@leeter Currently we are targeting -std=c++11. We could reevaluate if that does not suffice.

[ariya]

Is there a shared check list that can be used to track the progress? That way if someone wants to jump and help, we can avoid duplicated effort?

[dilijev]

@ariya Right now the closest thing we have to a checklist is our Roadmap. If it starts to change more frequently, we can explore another option. Do you have a preference or suggestion?

As for tasks that arise from this conversation beyond what the Roadmap indicates, please open issues and link to them from this issue so people can find their way around. (Same goes for PRs.)

I'll edit the main issue description to pick up the issue numbers as they come up so it's easier to track as this thread gets longer. (Sort of like a meta-issue.)

[dilijev]

I've just updated the cross-platform checklist to show which items are completed to my knowledge.

[ariya]

@dilijev Rather than doing it on the wiki page, here's my suggestion. Create a new issue for every platform, i.e. "Linux port", "OS X port", "BSD port", etc. For each issue, create a checklist. For every item in the checklist, link it to a more detailed issue or the corresponding pull request.

It seems tedious but a little-bit of project management aspect like this allows any interesting party to subscribe to a particular issue and get notified and/or participate accordingly. What do you think?

[dilijev]

It sounds good. I recently learned that GitHub picks up on checkboxes in an issue's description and marks it a percentage complete by how many are checked off. Meta-issues seem like the right idea.

It might be redundant but I think we'd still like to keep that progress tracked on the Wiki as well.

@EdMaurer what do you think?

[ariya]

@dilijev If the task list is nicely being tracked in the meta issue, is there a need to track it from the wiki?

[dilijev]

Fair point. We could link to the meta issue from the Roadmap page in the wiki.

[dilijev]

I noticed @caitp is tracking subissues related to her efforts in a similar way. https://github.com/caitp/ChakraCore/issues/1

[caitp]

the linux-posix work on my fork is pretty much a dead-end, so I probably won't be updating that checklist anymore, but it probably does highlight some common pain points of the cross-platform work.

[dilijev]

@ariya We've decided to keep the Roadmap in the wiki as-is. The Roadmap wiki page is an indication of our high level goals for approximately 6 months of work. We don't want to get into too much detail about the progress on those goals there. We'd prefer to track more detailed progress and coordinate with the community in an issue and let the Roadmap be comparatively static.

I'm not sure about specific plans for coordination. Last I heard, GitHub issues and Gitter are considered enough for now. If we have needs for something better we can discuss it when it comes up.

[trendzetter]

The roadmap mentions no JIT for linux, does that mean the performance will be inferior? Is this the intended behaviour?

[obastemur]

The roadmap mentions no JIT for linux, does that mean the performance will be inferior? Is this the intended behaviour?

IMHO...
Step by step. First interpreter only (it's almost there! see #873 from @digitalinfinity ), then JIT. Surely JIT performs better.

[dilijev]

That's right, our roadmap is for the short-term, next few months of work. We need to get the non-JIT version working first (which is strictly less complex), and then start working on JIT which is much more closely tied to the platform.

[trendzetter]

protip: Tools developed by Microsoft in a Windows first strategy should not be used for platform independent developments, they don't work well, they will haunt you. Node.org should be wise enough to keep Chakra at arms length.

[davidbabicka]

Step by step. First interpreter only..

then start working on JIT

Looking forward to try! @obastemur @dilijev any idea when?

protip: Tools developed by Microsoft....

Did you hear something nobody knows? or you are going to judge product a based on your protip opinions on product b?

By the way; could you answer who you really are first?

I see, it is very easy to produce a pure b.s. behind a nickname..

protip: stop trolling, do something useful or let people do something useful

[trendzetter]

@davidbabicka I enjoy your microsoft sponsored anger but it's misplaced. I am no troll, you see I make real contributions (contrary to your account it appears, talking about useful).
Microsoft has been pestering us for many long years to enjoy your anger for once.

[davidbabicka]

I enjoy your microsoft sponsored anger

Microsoft has been pestering us for many long years to enjoy your anger for once.

case closed..

p.s. I respect real people's work on this repository and no longer answer your b.s. Go and pick another nick name.

[dilijev]

@davidbabicka I believe we've got a hello world program running under Linux now. See: https://github.com/Microsoft/ChakraCore/pull/894

[obastemur]

Is there a reason to keep this issue open?

[dilijev]

@obastemur Probably not. I think we anticipated a high volume of issues and planning discussions coming from this but probably a better way is to open a new issue for each planning discussion and continue to tag Linux-related issues with Linux. Speaking of which, maybe we should add a Cross-Plat label to the set of labels we use.