Generate C APIs

Support
1

I was wondering how to generate C APIs using wrapping tool. The idea is that C APIs can be based to create binding to other languages such as Rust, Zig. Any guide with coding snippet would be appreciated. Thank you!

2

There have been discussions about generating C bindings, but no movement.

Personally, my primary interest is in using them for Python bindings so that the Python wrappers can “just” do cffi and be far more Python-version-independent.

Cc: @dgobbi @jaswantp @berk.geveci

3

I’ll plug my WrapVTK project once again. It doesn’t generate C bindings, but it generates a full XML description of the VTK C++ API, including full API documentation from the doxygen comments in the headers.

4

That’d be cool, but I’ll say this.

This may not be the answer your are looking for but there is a C API to create and modify few select VTK objects listed here and here .

The downside is that they not super efficient since it uses json strings to set/get property values and transform function arguments and return values. As a result, all the properties, function args, etc must be passed in as JSON strings.

5

This would be very useful for generating Julia bindings also. If someone from Kitware has time to investigate the level of effort involved before September 30th, I can provide a resource. Efficiency is somewhat important, but probably not super critical, since we usually pass large data structures as arrays. Parity with the existing wrappers is super critical.

1 Like
6

Activiz already does this!

7

Doesn’t Activiz provide C# interface? I did not know it also had C API.

8

The C# assemblies pinvoke the C dll API.

Of course the generation of those DLLs is horribly coupled into the project generation via CMake.

9

link to the detail please?

10

Activiz is no longer open source and Kitware has removed all links about how to build the legacy code for VTK 5.8.

The code looks like this from vtkPolygonEL.cxx

//----------------------------------------------------------------------------
//
// This file was machine generated by:
// mummy version 1.0.3 (revision 599)
//
// Manual changes to this file may be overwritten by the next build.
//

//----------------------------------------------------------------------------
// You can use this symbol in your header files if there are bits of your
// code that should be conditionally compiled in this export layer.
//
#define MUMMY_EXPORT_LAYER_CXX

//----------------------------------------------------------------------------
// Do not emit the silly C4996 warning for strncpy use:
//
#ifndef _CRT_SECURE_NO_DEPRECATE
#define _CRT_SECURE_NO_DEPRECATE
#endif

//----------------------------------------------------------------------------
// Forward declare functions that generated code might call...
//
#ifdef _WIN64
extern "C" __declspec(dllimport) void* __stdcall CoTaskMemAlloc(unsigned __int64 cb);
#define MUMMY_STRING_ALLOC ::CoTaskMemAlloc
#else
#ifdef _WIN32
extern "C" __declspec(dllimport) void* __stdcall CoTaskMemAlloc(unsigned long cb);
#define MUMMY_STRING_ALLOC ::CoTaskMemAlloc
#endif
#endif

#ifndef MUMMY_STRING_ALLOC
#define MUMMY_STRING_ALLOC malloc
#endif

//----------------------------------------------------------------------------
// Macro for exporting functions implemented in this file...
//
#ifdef _WIN32
#define MUMMY_DLL_EXPORT __declspec(dllexport)
#else
#define MUMMY_DLL_EXPORT
#endif

//----------------------------------------------------------------------------
#include "C:/Users/toddm/workspace/3RD_PARTY/VTK-8.1/vtk/Common/DataModel\vtkPolygon.h"


//----------------------------------------------------------------------------
#include "MummyRuntime.h"
#include "string.h" // for possible memset use
#include "vtkObjectBase.h"


//----------------------------------------------------------------------------
extern "C" MUMMY_DLL_EXPORT
vtkPolygon* vtkPolygon_New(unsigned int* mteStatus, unsigned int* mteIndex, unsigned int* rawRefCount)
{
   vtkPolygon* rv = 0;

   rv = vtkPolygon::New();
   if (0 != rv)
      {
      vtkObjectBase* ro = (vtkObjectBase*) (void*) rv;
      Kitware::mummy::TypeEntry* entry = Kitware::mummy::Runtime::GetTypeEntry(
         (void*) rv, typeid(*ro).name());
      *mteStatus = 0;
      *mteIndex = entry->GetIndex();
      *rawRefCount = (unsigned int) ro->GetReferenceCount();
      }

   return rv;
}

//----------------------------------------------------------------------------
extern "C" MUMMY_DLL_EXPORT
void vtkPolygon_SetUseMVCInterpolation_40(vtkPolygon* pThis, bool _arg)
{
   pThis->SetUseMVCInterpolation(_arg);
}


//----------------------------------------------------------------------------
extern "C" MUMMY_DLL_EXPORT
int vtkPolygon_Triangulate_42(vtkPolygon* pThis, vtkIdList* outTris)
{
   int rv = 0;

   rv = pThis->Triangulate(outTris);

   return rv;
}
11

Quick pivot with WrapVTK generated xml then fed into AI coding tool for a single file vtkImageViewer2, seem to be promising, not sure about its consistency though. Link to generated code here:

12

any latest unofficial oss code that we can try?

13

Good, the generated C wrapping looks like what I’d expect. Using WrapVTK would be robust for this. There is no oss code that creates C wrappings of vtk classes afaik.

14

The open source version of Activiz used Mummy (GitHub - gccxml/mummy) with CableSwig (GitHub - gccxml/CableSwig) to produce the wrapper code.

It depends on gccxml which is really old so I modified the repository here GitHub - todoooo/mummy to use CastXML (GitHub - CastXML/CastXML: C-family Abstract Syntax Tree XML Output) instead.

I also made some minor changes to CableSwig here GitHub - todoooo/CableSwig.

@Nikon_Sugar If AI can produce suitable bindings from XML then probably CastXML is all you need. Here’s the xml output for vtkPolygon. vtkPolygon.xml (88.1 KB)
See if it provides a useful starting point for AI code generation.