This project is not intended for production use. The tool is primarily being developed for my personal needs — to generate C APIs for C libraries from IDL specifications, as well as to automatically wrap the resulting C libraries for other languages, enabling them to be used as native libraries.

Below is an online demo of the compiler:

For example, the IDLC tool itself uses its own functionality to generate its API:

here are the IDL specifications for the library;
here’s the CMake target setup for generating C headers (idlc_compile function);
and here are the resulting headers produced during the build.

idlc_compile function monitors changes in the specs (.idl files) and, if necessary, rebuilds the headers in the ./include/idlc directory. These headers provide declarations for the C API, which is implemented by the C++ library. Of course, these headers are committed and distributed alongside the library.

Even for this online demo, the tool uses itself to generate the JavaScript library, packaging the WASM module for native use in JavaScript code. Exposing an API that has classes with methods, properties, and other familiar constructs.

The compiler is distributed as a library with a C API for embedding, as well as a command-line tool for standalone compilation. In other words, it can be used both as an embedded compiler and as a separate tool.

As for the IDL language itself — it is an abstract language not tied to any specific programming language but designed to accommodate a wide range of languages. For example, it supports properties and case-sensitive symbols, but it does not allow two different symbols that differ only in case (due to case-insensitive languages), and so on.

The workflow of this tool can be roughly represented by the following diagram:

Diagram

While this project is not intended as an industrial-grade solution, it serves as a practical example of:

building host tools as dependencies;
integrating them into a build system.

Why a new IDL language? Traditional Interface Definition Languages (IDLs) consistently fall short in achieving true cross-language interoperability. Most of these languages try to impose a "lowest common denominator" approach, which makes them awkward and unnative to use everywhere. This leads to context blindness — not adapting to linguistic idioms:

Creates unnatural APIs across all target languages.
Requires manual adaptation of generated code.
Fails to respect language-specific idioms.

For example, differences in working with arrays:

In C: typically requires (pointer, length) parameter pairs
In Modern Languages: native array types handle bounds automatically

This language overcomes this by generating APIs and automatic wrappers for C, so that the API can be used natively in any supported language.

@idl
@ API Sample
api Sample
 
@ Sample func
func ProcessData
    arg Items {Float32} [array(Count)] @ Item values
    arg Count {Uint32} @ Number of items

Usage in C:

@c
float items[] = { 3.2f, 4.5f, 1.2f };
sample_process_data(items, 3);

Usage in JavaScript:

@javascript
// Uses native array types with built-in bounds
// function processData(items: number[]);
 
const items = [ 3.2, 4.5, 1.2 ];
module.processData(items);

For a step-by-step guide on embedding the compiler into your project (to enable API support and generate native wrappers for other languages), check out the Quick Start.

Next
Quick Start