When generating bindings, we’re not transpiling C++ to C#.
Instead, we inspect the result binaries, demangle all names and work mostly with pointers or references to block of memory.
Inline functions are problematic because despite being part of the public API, they’re not visible when inspecting compiled libraries. They’re instead baked in each consumer of that API.
To solve this, I am thinking of using a “glue” library that explicitly exports all inline functions as PInvoker-friendly symbols.
Do you have examples of inline functions in Haiku public APIs? I can’t think of much. We do have templates, however, for things like BLayoutBuilder. But that kind of thing is probably better to reimplement natively in C#, anyways?
Template classes, template functions, inline functions or anything that is not present as an exported symbol of the library are equally challenging to bind.
But that kind of thing is probably better to reimplement natively in C#, anyways?
It depends.
Reimplementing things in C# require maintaining another version and will break if Haiku decides to change any of these template classes. For some stable, small, and performance-critical classes that have a large number of instantiations it might be worth it.
For BLayoutBuilder, I think it’s best to create a glue library that exports an instantiation where ParentBuilder = char. BLayoutBuilder classes seem to use pointers with everything, and templates here seem to be only meaningful for type checking, which we can erase at the language interop level, but restore at the C# language level.
But I do thing it’s important that it’s easy to install and use with what we have ready, what ewer part it is. Thats what’s make c# on Windows so easy, it’s just works…
Note that this requires a Linux machine. Also, only some primitive tests are passing, nothing else is really running yet. This is the .NET port’s status as of last year.
While things seemed to work a few months ago, everything is broken today.
PAL tests seem to be passing, but there’s some bug related to the JIT, at least on HyClone.
Native Haiku didn’t even get that far to reproduce the bug but segfaults instead.
If this project is to be accepted, it will surely be an interesting and long one.
Behold, the first .NET 8.0 binary running on Haiku.
(The first binary ever was for .NET 7.0 in last year’s effort).
At this stage, it is theoretically possible to run many computation-heavy .NET apps such as the Roslyn C# compiler given enough effort to set up a correct environment.
The source code for this year’s CoreCLR porting effort looks much cleaner, but there are still a few final issues that have to be resolved. I’ve talked about these problems on the IRC channel, but if you’re interested, I can write a blog update this weekend.
Blog posts are important for long term archival and tracking of the work done. It’s not very convenient to have to find informations about things on the IRC channels after a few years have passed, whereas blog posts can more easily be found and reused.
