COMMUNITY

Shoutout: Are there any members here who have a working haxe build-from-OCaml-sources environment on their local Windows machines?

Hi all,

This post is directly related to:

https://community.haxe.org/t/how-to-implement-new-haxe-target/1599

so maybe it’s against the rules to ping it here, but I’m afraid it might get buried if I don’t make a new post:

The above post describes my (as-yet unsuccessful) attempts at setting up an environment on my Windows 10 machine to build haxe from OCaml sources.

Here, all I would like to know is:

Is there anyone who actually HAS a working setup to build haxe from sources, on Windows?
If so, how did you achieve this?

I will keep on trying, but I’d rather start working on my actual target and thereby actually contributing to haxe, than spend many more weeks on just getting haxe to finally compile…
Bad analogy: I feel like I’m having to build a factory, just to create some pots and pans, when what I actually want to do is cook a meal… (as it were).

I badly want to contribute, because I love haxe, and haxe’s ultimate strength lies - in my humble opinion - in having as many strong output targets of high quality as possible.

:upside_down_face::haxe::slightly_smiling_face:

I build Haxe on Windows. It was a pain to set up initially, but it was long time ago. Nowadays I’m using fdopen ocaml installer and that works for me. In fact, these build instructions was originally written by me. They might be a little outdated nowadays, but the principle hasn’t changed.

I think I have OCaml 4.03 installed that way, using 64-bit installation instead of 32-bit. And remeber - you have to install opam packages via cygwin prompt, not normal cmd.exe/powershell, but other stuff needed to build Haxe works for me from powershell in that setup.

I wouldn’t be surprised that if you already have some other cygwin/mingw/etc. installed in your path, stuff might conflict, but on a fresh system it should work.

1 Like

Thanks @nadako

Would it be possible for you to share here:

  • The actual locations of all the relevant puzzle pieces, like e.g.:
    ** C:\OCaml…
    ** C:\CygWin…
    ** C:\Haxe\sources…
    ** etc

  • All the relevant environment variables, as well as you PATH?

  • Anything else that might have any influence on the whole thing?

Many thanks!

Cygwin is installed along with ocaml by the fdopen installer to C:\OCaml64, the actual ocaml binaries seem to be in C:\OCaml64\home\nadako\.opam\4.03.0+mingw64c, haxe repo is simply (recursively cloned) to some directory and I run make -f Makefile.win from it (I’m not sure if that’s still needed tho).

env vars:
OCAML_TOPLEVEL_PATH C:\OCaml64\home\nadako\.opam\4.03.0+mingw64c\lib\toplevel
OCAMLLIB C:\OCaml64\home\nadako\.opam\4.03.0+mingw64c\lib\ocaml
OCAMLRUNPARAM b (this one is merely for full stack traces)

and then in PATH:
C:\OCaml64\bin
C:\OCaml64\usr\local\bin
C:\OCaml64\home\nadako\.opam\4.03.0+mingw64c\bin
C:\OCaml64\usr\x86_64-w64-mingw32\sys-root\mingw\bin

(BTW those go after git C:\Program Files\Git\cmd, so the installed git takes precedence, because IIRC cygwin will install its own and that won’t work from normal windows shell)

So, basically it’s the same as in the instructions :slight_smile:

1 Like

I was able to build Haxe on windows, simply following instructions on GitHub. Didn’t have problems. Only compiled haxe.exe crashed and I decided not to dig deeper.

1 Like

I’m not sure what exactly do you mean by “crashed”, but the compiled .exe can indeed not work because of incompatible .dlls take precedence if they are higher in PATH than the correct ones. Example: I once had haxe.exe compiled for 32-bit but then I also had 64-bit Postgresql installed and its bin directory was at the top of the PATH and it contained zlib1.dll which was picked up by haxe.exe and that failed because of different arch. The solution is to either copy proper dlls to the same dir where haxe.exe is, or fix your PATH.

This tool helps figuring this out: http://www.dependencywalker.com/

1 Like

Same. Had that crash first too but remember thay was a matter of putting path variables in certain order(?) I also have to admit I had no idea what I was doing but once it worked I never touched it again.

I compile the haxe.exe in the root of its git repo, so I can use the standard library from there.

1 Like

Could be dll issue. I compiled on windows 32 bit too. I didn’t see any error messages for any ideas what to do next. Good to know.

1 Like

Not sure about path variables order, it was about year ago. Problem with this, you have to do it once and forget so no one clearly remember how to do it correctly :slight_smile:

1 Like