feature: C# binding to MOAB C++ API for dotnet core and .net framework

Issue #136 resolved
Former user created an issue

Tested with maob example1 write vtk mesh.

This work is done by UKAEA (United Kingdom Atomic Energy Agency), would you accept this feature as part of MOAB source tree as pymoab, or as an independent repo, in https://bitbucket.org/fathomteam/
or https://github.com/ukaea

let us know.

Comments (7)

  1. Vijay M

    We would be happy to add C# bindings for MOAB if you can submit a PR. Please refer to CONTRIBUTING.md document about the process.

    I do not see a listing for MOAB fork in the UKAEA github link. Please provide a valid pointer so that we can discuss how best to integrate the new bindings into the repository. Thanks.

  2. qingfengxia

    the code is yet published, may need some approval

    The binding is generated by my patched CppSharp with manually fix before compiling. I also made some change to MOAB source code, that must be merged into MOAB master/main.

    Not all API are generated, only needed for Trelis_plugin are binded.  I have no plan to bind the complete MOAB API. My preference will be an independent repo to host, to reduce the work to maintain/sync. The binding code relies on ABI stable.

                module.Headers.Add("moab/iMOAB.h");
                module.Headers.Add("iMesh.h");
    
                module.Headers.Add("moab/FileOptions.hpp");   // always fwd declareCppSharp does not know where is the def
                module.Headers.Add("MBTagConventions.hpp");   // macro constants are not exported?
                module.Headers.Add("moab/Types.hpp"); 
                module.Headers.Add("moab/Interface.hpp");
                module.Headers.Add("moab/Core.hpp");   // this header include "moab/Interface.hpp" 
                module.Headers.Add("moab/GeomTopoTool.hpp");  
    

    In the future , only some important public API headers/classes will be supported. If automation build is possible, then can consider merge to MOAB like pymoab.

    Will post the link to code soon.

    Thank you.

  3. Vijay M

    Yes agreed. If the bindings are lean, and is only specialized to a subset of API in MOAB, you should keep it as a separate repository, where you can probably make MOAB as a sub-module. I’ll be happy to review and provide inputs when they are ready.

  4. Log in to comment