raph-amiard / camllvm Goto Github PK

Make closurerec and related instructions work as planned

just to let you know: Z3 is already the name of a great SMT solver, written in OCaml: http://research.microsoft.com/en-us/um/redmond/projects/z3/ so I'm not sure it's a good idea to call your compiler extension this way ...

One solution would be to use the Ocaml runtime for everything it provides, including :

• Marshaling of data, and reading of ocaml bitcode files
• Garbage collector
• Internal functions

The pros of this approach would be :

• No need to reimplement marshaling and all of stdlib functions that are implemented in C

The cons:

• Need to understand the codebase of Ocaml, which is in a different language (one more dependency)
• One advantage of making a ZAM->LLVM compiler is that we're not dependent on the evolution of the ocaml language and codebase. This advantage disappears if we use the Ocaml runtime

All vmkit source code does not use c++0x standard unlike Z3. I don't think we can manage to keep both as is and fix it automagically in the Makefile (Please prove me wrong!).

2 choices: we modify all of our headers or all of vmkit headers (yeah sure) to comply with only one standard.

Hi!

Did you ever get the OCaml GC to work with LLVM? I'm working on such a project now and I'm having some difficulties with this. Do you know any project that successfully integrated LLVM with the OCaml GC?

Regards
Olle

Without considering copyright issue, we are not supposed to "hack" the ocaml source files. So they should be outside of our git repo, in a separate directory, with a clear dependency.
Some $VARIABLE could be setup before compiling to point to the corresponding directory.

Moreover, git is actually tracking some files that are generated during the ./configure step.

Do we allow the use of C++11 features ?

This would certainly simplify some things in the code, at the expense of relying on experimental compiler features. I used some of them in my code.

My proposition is that we use the subset of features available in clang : Clang C++11 status

Since clang is already a dependency of the project (if we plan on integrating VMKit), it seems like a fair compromise.

What do you think ?