Moving to OCaml 4

[Simn]

I think it's time we do that. Is anyone still using OCaml 3 or was I the only one?

[andyli]

I think the HF PPA still have to support Ubuntu 12.04 for an year, until 12.04 reaches its EOL in April 2017.
If we move to OCaml 4, I have to tweak the Ubuntu 12.04 build to upgrade its ocaml version somehow, but that shouldn't be toooo hard.

[nadako]

That would be a good thing to do, so we can move away from camlp4o and start using new language extension framework for lexing/parsing, starting with #5163.

[Simn]

Glad to hear you're volunteering to rewrite the parser!

[nadako]

Haha :) Well I'm more interested in lexer, since this multi-byte issue is really annoying and it's even more annoying that the issue isn't obvious to them latin people :-P

[jdonaldson]

[ncannasse]

Today I tried to setup my laptop with OCaml 4.02 + MSVC 2015, was quite hard indeed.

• install MSVC 2015 community edition
• install OCPWIN 4.02 MSVC 64
• github co CamlP4 (no longer in ocaml install) : make configure, edit the config files for typos (replace backslashes in paths by slashes), then make all install
• ocpwin distrib does not like .obj, replace with .o in Makefile.win, remove shell32.lib
• our precompiled zlib.lib is ignored even after adding -cclib in front of it, maybe because it's only x86 ? recompiling it (requires building the zlibvc before zlibstat)
• works, at last

Resulting haxe.exe has dependency with VCRUNTIME140.DLL and universal CRT DLL as well. I would advice to use MingW for releases instead

I think we should advise users to use OCPWin MingW to compile and modify Haxe. Maybe with using my HaxeDevelop project as well ? But this requires extra tools in PATH (make, sed)

[ncannasse]

Ok, it seems we can keep the Makefile.win without MSVC=1 to compile for MSVC with OCPWin, it simply requires copying libs/extc/zlib/zlib.lib (or zlib64.lib which I have just pushed) into ocaml/lib/msvc-xx, then rename it as "z.a"

[nadako]

The "Building on Windows (Cygwin)" way, documented in http://haxe.org/documentation/introduction/building-haxe.html still works great for me (I just set up the environment on my notebook again). The only thing to mention is that you need a 32-bit version because there's no Neko 64-bit on windows.

[ncannasse]

Trying OCPWin-MINGW-Full:

• download and install OCPWin-MINGW-Full (32 bits)
• setup camlp4:
  • github co https://github.com/ocaml/camlp4
  • switch on good branch (4.02 atm)
  • bash configure
  • make all install
    • in error : replace \ by / in myocamlbuild_config.ml
    • in error : remove double quotes as well
• works out of the box! (using HaxeDevelop + haxe.hxproj)

So yes, getting rid of CamlP4 and using OCPWin-MingW seems like a quite convenient way of developing Haxe.

Some benchmarks:

• haxe MingW full evoland2 compilation : 29.6s
• haxe MSVC : 40s (a bit older compiler, I need to check with exactly same version but seems promising)

[ncannasse]

Did some additional benchmarks today, making sure that they were all done using the same Haxe version.

Compiling the full version of Evoland 2 (different computer than yesterday):

• 3.11/MSVC32 : 24.8s
• 4.02/MingW32 : 18.6s (using http://www.ocamlpro.com/pub/ocpwin/ocpwin-builds/ocpwin32/20160113/ocpwin32-20160113-4.02.1+ocp1-full-mingw32.zip)
• 4.02/MingW64 : 20.4s (using http://www.ocamlpro.com/pub/ocpwin/ocpwin-builds/ocpwin64/20160113/ocpwin64-20160113-4.02.1+ocp1-full-mingw64.zip)
• 4.02/MSVC32 : could not compile (see Missing libasmrun.a? OCamlPro/ocpwin-distrib#16)
• 4.02/MSVC64 : didn't try
• 4.02/MingW32 without -g : 18.6s as well

I would have like to see 4.02/MSVC32 to know if these 30% performances gain came from either 4.02 or using MingW toolchain. I suspect the former because as far as I understand OCaml only use the assembler and linker of the toolchain, so there is no compiler-specific optimization being performed (only for C the parts, but they are rarely called).

I would advise that we make Windows releases with MingW32, and that we update the build instructions for windows in order to have people using OCPWin for MingW.

[nadako]

What's our stance on using opam and ocamlfind? I was looking into integrating sedlex extension today (for #5163), but it has a couple of dependencies (gen, ppx_tools) and to integrate it like others (into the libs dir), one would have to rewrite the makefiles.

I feel like the right thing to do is to do everything the opam way (of course everyone will need to setup proper opam environment, but that's another story).

[nadako]

OCPWin is simply impossible to set up for us windows peasants. It implies having a working cygwin/mingw/whatever environment.

The solution I found is the awesome OCaml distribution for windows by @fdopen. It's very easy to install and has everything we need to build Haxe on Windows. Moreover, I had no problems with opam installing Merlin and other packages - it just works. So I strongly recommend it. I wrote a step-by-step instruction that worked for me and @Simn here: https://gist.github.com/nadako/1e73ee2fa759d2ea9bf4acb65e3e3052.

I think we should embrace opam packages and ocamlfind, because otherwise, using e.g. sedlex is a huge PITA (unless I'm missing something ofc). And I want this to go further because of #5163 (I made a working branch for utf8 lexing support using sedlex). So, let's discuss it and decide soonish! \o/

[Simn]

This is pretty much concluded because @nadako's instructions work like a charm. As an added bonus we now get to have a good IDE due to this VS Code plugin: https://github.com/hackwaly/vscode-ocaml

I forget, was there anything special we had to do for merlin to work? Might be worthwhile to add that to the instructions.

Other than that we only have to port Hugh and then we're done.

[ncannasse]

Are there some issues if you have already Cygwin installed ? Asking potential contributors to uninstall their working software does not sound like a good idea :)

[Simn]

Pretty sure that would work regardless, it's most likely just the "I don't want to deal with problems that come from existing installations of something" clause.

[Simn]

I think we can close here.