Migration to dune

[Simn]

This mess tries to get Haxe working with the dune build system. At the moment, nothing works.

Prebuild

We can manually run this sequence:

dune build src-prebuild/prebuild.exe
./_build/default/src-prebuild/prebuild.exe define src-prebuild/define.json > src/core/defineList.ml
./_build/default/src-prebuild/prebuild.exe meta src-prebuild/meta.json > src/core/metaList.ml

Ultimately, we want to handle this like grammar.ml is handled. There's a dune file in src/syntax with this content:

(rule
	(targets grammar.ml)
	(deps grammar.mly)
	(action (run %{bin:camlp5o} -impl grammar.mly -o %{targets}))
)

In the case of prebuild, I couldn't figure out who is supposed to make sure the .exe is built, and how to reference is from the action.

For now I have added both defineList.ml and metaList.ml to the source so we can get other errors.

Update: Solved by edf1bdc

version.ml

This currently uses a dummy rule:

(rule
	(targets version.ml)
	(action (write-file version.ml "let version_extra = None"))
)

We'll have to look into how to migrate this whole ADD_REVISION business.

Update: Solved (not very prettily) by 212c506

Meta naming conflict

File "_none_", line 1:
Error: Files src/.haxe.eobjs/native/meta.cmx
       and C:/Users/simn/Documents/.opam/4.06.1+mingw64c/lib/ocaml\compiler-libs\ocamlcommon.cmxa
       both define a module named Meta

I couldn't find a solution for this yet. There's a stackoverflow question where the answer at the bottom suggests that module files can be wrapped, but I couldn't get that to work.

This has to be solved before we can do anything really... I would like to avoid renaming our Meta module because it's the most referenced module in our codebase (of couse it is).

Update: Solved by adding (wrapped_executables true) to dune-project.
Update: Solved again by not linking sedlex.ppx, which avoids pulling ocamlcommon.cmxa. We no longer wrap executables.

Native C

I didn't get to the part where we deal with native C bindings for extc and pcre yet. There's an example in the dune quickstart guide that should be easy to adapt:

(library
(name mylib)
(public_name mylib)
(libraries re lwt)
(c_names mystubs)
(c_flags (-I/blah/include))
(c_library_flags (-lblah)))

Update: Kind of solved, but there's a stupid hack for objsize to find its dependencies.

Release vs. dev env

Right now, we can only build anything with --profile=release. Building in the default dev mode just generates a video of OCaml developers laughing at our codebase, by which I mean that there are lots of warnings-turned-errors that we have to fix.

Explicit library opening

I think we way this works is that we're supposed to explicitly open Extlib_leftovers in places where we use its types. This is slightly annoying, but should be a one-time change. The only issue is that the current makefile-based building no longer works because libraries are implicitly opened there.

Update: "Solved" by using (wrapped false), but ultimately we should fix this in our codebase I think.

[Simn]

We should be good here. Some remarks:

• main.ml is now haxe.ml as required by dune.
• libs and clean_libs are no longer valid makefile targets.
• The way we currently deal with version.ml and LIB_PARAMS is a bit hacky and causes an initial delay when building. We should look into a better solution for this, but it's fine to merge it for now.
• There was a lot of stuff in the makefile so there's a chance that I missed something. I'm sure @andyli will tell me.

Before merging I would like @Aurel300 and @RealyUniqueName to confirm that make haxe still works for them locally, and that the generated executable has a sane size.

[Simn]

Note that when checking out this branch you'll probably need a git clean -dfx in the libs directory because there might be build artifacts from previous builds there.

[jonasmalacofilho]

Works flawlessly here!

[kLabz]

❤️ 🚀

[Simn]

I realized that the dune commands would scan all subdirectories, which caused the delay I was experiencing. I've added a toplevel dune file to ignore these directories, which now makes prebuild compilation near instant.

I had to add a workaround DUNE_COMMAND to the makefile because on Windows it would try to execute that new dune file instead of dune.exe... That shouldn't happen on real operating systems though.

[Aurel300]

Do we still need the suffix rules?

[Simn]

Probably not.

I was thinking that we could absorb most of the makefile into the prebuild program anyway. That should be more fun to maintain. We would then just use the makefile targets to pass information to prebuild.