add native Windows compiler support

[dch]

Microsoft's native Visual C++ compiler is used to build Erlang from source.
For NIFs to be loaded successfully into the Erlang VM, and run stable, they
must be built against the same VC++ runtime, and using the same compiler as
was used for building the VM itself.

[dizzyd]

Yes, I would like to understand the impact this would have on cygwin/msys/mingw users. It seems like a fine thing to do, but we need to do some detection so that you can have win32-cyginw and win32-vc or something.

[andrewtj]

You might have to bring this up on erlang-questions to get more input from Windows users. I don't know the platform that well but I'd guess that a config option nominating the build environment will be required.

[MattVonVielen]

If there's any help or input I and my team can give, please feel free to drop me a line! Our current project is a Windows service in Erlang/OTP and it's starting to look like we'll need rebar compilation support for NIFs and port drivers in the upcoming phase of our project (I.E. very soon).

[dizzyd]

So do we need to distinguish between compiling with VC and cygwin? Would the platform string look like win32-vc and win32-cygwin?

[dizzyd]

To reiterate -- do we need to distinguish between VC and cygwin? If not, then I'm ok to merge this.

[dch]

After a long hiatus I rebased this change onto recent rebar to use port_specs etc. Hopefully we can find a common solution.

1. We agree that we need to support 2 compilers and 3+ shells, at least on windows, e.g.:
   • cmd or ps1 shells + MSVC
   • mingw/gcc
   • mingw/MSVC
   • cygwin/gcc (anybody using that?)
   • cygwin/MSVC (same as core erlang)
2. Ideally switching between these would be a simple environment variable or rebar.config setting, not the 10 vars in this patch.
3. I don't see an immediate solution in rebar_port_compiler to handle this use case, but I could see the need for different compilers turning on on other platforms, especially solaris/illumos variants. Generally setting CC and CXX is sufficient in that case.

The attached patch works fine for my needs - generic unix/mac support + windows working, and with a customised shebang file I can distribute these within my projects if required. But this approach doesn't work wrt 2. and 3. above.

What about if rebar took os:type() and then, for windows, extended it as follows:

• what shell it was running under
• what compilers are available (first MSVC, then gcc)

Then we could use {win32, cygwin/msvc} {win32, mingw/gcc} etc etc to set defaults cleanly in rebar_port_compiler that largely Does The Right Thing. And it should be possible, within a project, to force a specific combination if needed.

Thoughts?

[MattVonVielen]

First of all: I've come to the conclusion that the shell question is an utter "red herring." As far as I can determine, any application that calls exec(3) or equivalent will always end up inside a cmd.exe instance. This goes for ruby/rake, jruby/rake and erts/rebar at a minimum, and those are just the things I've personally used. So if we're on an NT OS, we should always expect cmd.exe shell syntax.

I'm personally fine with having a default compiler toolchain of GCC - I would, however, appreciate not having to set a lot of different port_env(s) in all of my MSVC based projects. Along the lines of @dch's idea, if there were some way to provide "named" port_env's so I could just say something like {port_env, msvc} in my config then that would be a big win.

[dch]

On 2 June 2012 04:09, Matt Campbell
reply@reply.github.com
wrote:

First of all: I've come to the conclusion that the shell question is an utter "red herring."  As far as I can determine, any application that calls exec(3) or equivalent will always end up inside a cmd.exe instance.  This goes for ruby/rake, jruby/rake and erts/rebar at a minimum, and those are just the things I've personally used.  So if we're on an NT OS, we should always expect cmd.exe shell syntax.

An excellent point regarding spawning new procs. But if you are
running mingw/make/gcc then gcc will not be spawning cmd.exe, it will
be using bash instead. So the waters are somewhat murky, despite the
presence of a large school of herring beneath most of the time.

I'm personally fine with having a default compiler toolchain of GCC - I would, however, appreciate not having to set a lot of different port_env(s) in all of my MSVC based projects.  Along the lines of @dch's idea, if there were some way to provide "named" port_env's so I could just say something like {port_env, msvc} in my config then that would be a big win.

+1 that's kinda what I'd like to see.

Matt - how do you manage your port_env settings today? In rebar.config
per project/dependency, or somewhere else?

---

Reply to this email directly or view it on GitHub:
#157 (comment)