How to deal with functions not present in the C++ API?

[TChatzigiannakis]

Consider, as an example, the function LLVMCreateJITCompilerForModule.

LLVM C API signature:

LLVMBool LLVMCreateJITCompilerForModule(LLVMExecutionEngineRef *OutJIT,
                                        LLVMModuleRef M,
                                        unsigned OptLevel,
                                        char **OutError)

LLVMSharp C API signature:

LLVMBool CreateMCJITCompilerForModule(out LLVMExecutionEngineRef outJit,       
                                      LLVMModuleRef m, 
                                      out LLVMMCJITCompilerOptions options, 
                                      int sizeOfOptions, 
                                      out IntPtr outError)

How do we include this in the LLVMSharp OO API?

Option 1

Create a static overload of it (in the LLVM class - or preferably in a new static class, dedicated to the OO API), with the class types in the signature.

(This is the easiest approach, but it's not how the LLVM C++ API is exposed. So in doing this, we still create an OO API but we depart from the idea of porting the LLVM C++ API specifically. If we're willing to do that, there's also option 2.)

Option 2

Expose each of these functions as an instance method of the type of its first non-out parameter. In our example, CreateMCJITCompilerForModule would be an instance method of the Module class.

For functions that don't have a non-out parameter, we fall back to static overloads (option 1).

(This is how I have it right now in the development branch.)

Option 3

We attempt to stay faithful to the C++ API and we start exposing more things, like the llvm::EngineBuilder class that used in the implementation of LLVMCreateMCJITCompilerForModule, instead of exposing the function itself.

(I think this would be ideal, but I doubt that it's feasible without ending up re-implementing the entire LLVM C++ API, which means duplicated C++/C# code.)

[mjsabby]

I prefer Option 2, for consistency with how we've done things elsewhere.

Option 3 is not feasible, and I don't think folks really necessarily care about the parity that much.