Support for mingw/msys/cygwin for node-gyp

[smaudet]

The authors claims that mingw is not a viable target for node-gyp on windows I believe to be patently false.

I would like to patch node-gyp to allow it to correctly build msys compatible make files, for versions of nodejs built with the msys/gcc toolchain.

From my research so far, this is not only possible, but partially already supported. Two things need to happen:

1. Stop assuming that only msvs is supported on windows
2. Add an msys make target with the following properties:
   a) support /c/
   b) No colons are allowed in e.g. /C:/
3. link to appropriate msys versions of libraries.

If those conditions are met, it appears that node-gyp generates/builds just fine on msys nodejs, contrary to the author's wild claims to the contrary.

Referencing these old tickets in case there's anything of value/relevance in them:

#194
#280
#660

[bnoordhuis]

If it's a few small unobtrusive changes, that might be fine. If it's going to take major surgery and ongoing maintenance effort, the answer is 'no'.

Building node with mingw isn't supported so there is only marginal value in supporting it in node-gyp. You won't be able to load a mingw-compiled add-on in a msvs-compiled node, or vice versa.

If you are serious about this, you should upstream your changes to nodejs/node first.

contrary to the author's wild claims to the contrary

Lay off the condescension, will you? What are you, a twelve year old?

[smaudet]

Major surgery etc are unlikely to occur. Unless linux becomes an unsupported platform (in which case I'm likely to ditch nodejs entirely), gcc support is available, and while gcc support is available, mingw support is not much of an effort.

There might be some retraining required down-stream (if people are doing awful things with their node-gyp files).

As for upstream, the version I'm using is based on a patch engine that somebody else is reponsible for (credit to Alexey Pawlow https://github.com/Alexpux).

I'm unsure what his effort on this issue is. His stuff works fine.

As for 'condescension', all it took me was a minor bit of googling and a bit of playing around to figure this stuff out so far. The node-gyp authors can't have even tried.

[bnoordhuis]

Yeah, because we're well aware of the cost/benefit ratio. The point stands that as long as upstream node doesn't support mingw, supporting it in node-gyp is of extremely marginal utility.

You are welcome to open a pull request but if I deem it too invasive or too much of a maintenance headache, I'll have no qualms about rejecting it.

[smaudet]

'Just works' support for msys is fairly big benefit. Dealing with required admin access to machines/bulky msvs compilers with large buggy .NET dependencies is a fairly major drawback.

I think you're thinking too small. Short term cost is high, sure, but the long term benefits are much bigger.

[bnoordhuis]

As long as this is an issue:

You won't be able to load a mingw-compiled add-on in a msvs-compiled node, or vice versa.

mingw will always be a fringe thing. I would be more supportive of clang-cl support, it's ABI-compatible with msvs.

[smaudet]

This is getting very off-topic, but, maybe. But I'm not aware of any clang-cl based runtimes - sure that's a nice idea, but where's my pacman on windows and my bash?

Also, I've not followed up with the windows 10 linux subsystem, but I'd think that'd make stuff like this more prevalent, not less. Perhaps eventually msys2 morphs into another compatibility layer there?

At any rate, you seem to be more intent on talking about why its a bad idea, I'll focus on actually coding, thanks.

[bnoordhuis]

But I'm not aware of any clang-cl based runtimes

I don't know what you mean by that. clang-cl is a front-end to clang that emits msvs-compatible machine code (same C++ name mangling, calling conventions, etc.)

mingw uses its own name mangling scheme that makes interoperability impossible.

At any rate, you seem to be more intent on talking about why its a bad idea, I'll focus on actually coding, thanks.

You go, kid. And I, I'll go close out the issue.

[smaudet]

Um, why close it? I'm still working on this.

[bnoordhuis]

You rather clearly indicated the discussion ran its course. Looking forward to the PR.

[smaudet]

Ah, ok. I have to go to work here in a bit, so there probably wont be anything from me for a couple days. I was under the impression it should stay open until there was a PR.

[gibfahn]

Also, I've not followed up with the windows 10 linux subsystem, but I'd think that'd make stuff like this more prevalent, not less.

If you're in the subsystem you have full access to gcc, what's the usecase for using mingw?

I would like to patch node-gyp to allow it to correctly build msys compatible make files, for versions of nodejs built with the msys/gcc toolchain.
it appears that node-gyp generates/builds just fine on msys nodejs,

Have you tried contributing your msys nodejs support into nodejs?

Dealing with required admin access to machines/bulky msvs compilers with large buggy .NET dependencies is a fairly major drawback.

Have you tried http://landinghub.visualstudio.com/visual-cpp-build-tools ?

[smaudet]

In short @gibfahn :

1. Not in it.
2. Not mine.
3. Not applicable to me.

Small update, but currently working on linking, something (I don't know what), triggered name mangling issues in my build. Before I contribute anything to node-gyp I may need to back up a step and make sure my knowledge of linking against msys-nodejs is sound.

I've only spent about an hour looking at the name mangling, I'm fairly happy with my progress in terms of cost/duration.

[smaudet]

There was a longer comment here about node-gyp - I figured out how to read name mangling from compilers.

The primary cause of my confusion has been understanding which manglings were expected. I think there is an opportunity for a name mangling database or translator of sorts (perhaps something from the llvm project to help out?) to assist with these sorts of build issues. I think as it stands node-gyp can be made to work with a little effort, however I have some patches to submit against the mingw nodejs project as well.

[smaudet]

Some good news, I have it working.

By that I mean, I have patches that produce correct build files for nodejs on mingw, and I have the hello world example building.

Now comes the hard part of building reproduce-able patches.