search

mono / SkiaSharp

SkiaSharp is a cross-platform 2D graphics API for .NET platforms based on Google's Skia Graphics Library. It provides a comprehensive 2D API that can be used across mobile, server and desktop models to render images.
MIT License
4.48k stars 538 forks source link

[QUESTION] Generate C API automatically? #1003

Open ngocdaothanh opened 4 years ago

ngocdaothanh commented 4 years ago

Related to https://github.com/mono/SkiaSharp/issues/1002:

https://github.com/xoofx/CppAst can parse C++ headers, so can we generate C API automatically too?

The benefit is huge, as there's no need to manually write C API (and fork Skia) any more.

Gillibald commented 4 years ago

https://github.com/SharpGenTools/SharpGenTools

mattleibow commented 4 years ago

Been a long time since you asked, but this is something I am wanting to do.

There are a few reasons why this is not done yet, the simplest is that I just haven't gotten around to it. It is a bit of work, and it needs to be done.

Other reasons is that the actual C++ API is a bit varied and will make tools a bit harder to write. However, this is no reason why we can't do it.

On thing that I do when I generate the C API is that I decide what/how I want objects to exist. For example, we could magically generate everything, but I actually want the small, frequently used objects to be structs - SKSize and SKPoint. I don't want to cross the managed/native bridge too often. This has to be taken into consideration.

The reason I am not doing this is that the C API is not particularly time consuming or complex to maintain. I have a few other projects that take up a lot of time so writing a few lines of C every so often is not so bad. Obviously, as time goes on, I would probably save time, but...

Just want to say: PRs are welcome and probably you (or anyone in the community) might be able to do it better.

mattleibow commented 4 years ago

On the point of the don't fork the native repo, I don't think this will be possible in the near future because of the non-API changes required. We could upstream them, but this also needs to be done.

Some of the things that we change to support our feature set are additional platforms as well as managed-only features that Google probably doesn't want in their code.

I have no problem about parsing C++ and generating C into the repo, but dropping the fork is not going to be something that will be looked without some serious consideration and discussion.