How do I start using this?

[GitMensch]

I have existing makefiles (written for gcc), that use a CC variable for the C compiler.

• How do I get Cesium (how for Windows, how for Ubuntu) starting from a "bare OS install"?
• What do I need to place into CC to use it?
• Am I right that I need to compile any dependencies with Cesium first? If not: can I just link those libraries?
• Can I still use native code (parts written in assembly)? If yes, how?
• Are the C integer types stored identical in memory when using cesium as they were with gcc?

[ForNeVeR]

Hello and thank you for your interest!

I have existing makefiles (written for gcc), that use a CC variable for the C compiler.

Let me note first that Cesium is really far from being useful right now. Eventually, we want to cover this case (exactly using Cesium as CC= in make), but right now this is impossible. Below, I will consider your questions from both the standpoint of the current situation and the future plans. But please mind that right now Cesium is most likely not useful for you. Sorry. We are working on it!

How do I get Cesium (how for Windows, how for Ubuntu) starting from a "bare OS install"?

Currently, you get it by:

1. Get a .NET SDK installation (already packaged for all the major operating systems by Microsoft and the OS maintainers).
2. Clone the repository from GitHub.
3. dotnet publish, as documented (though we could improve the documentation to mention other operating systems; we support them, of course).

This will generate a native binary for the chosen OS with relatively the same dependencies as dotnet runtime for the particular platform has. For example, here's the dependency list for Ubuntu. Most notably, that's libicu and libunwind; everything else is relatively common AFAIK.

In the future, we will also distribute Cesium in the form of .NET SDK, and will likely publish the prebuilt binaries for major operating systems ourselves (of course, it will always be possible to just build it from sources).

What do I need to but into CC to use it?

Not sure I get the question correctly. Currently, Cesium binaries cannot be used as CC for your Makefile. We will consider this usage variant later (I already have thoughts on how it will work), but perhaps a .NET SDK will come first (to use Cesium in .NET solutions alongside other .NET languages).

Am I right that I need to compile any dependencies with Cesium first? If not: can I just link those libraries?

Let's say that for now the interop model is not so thought out as some other things, but what I can (try to) promise is that the Cesium interop model will be at least as sufficient as the model for C# is. So, if you can interop some library with C#, you will be able to interop it with Cesium as well (and here I mean native libraries).

Perhaps the closest RFC here is #511, about #pragma pinvoke.

To emphasize: currently, the native interop model is mostly non-existent. We will improve and consider it though.

So, in the future, you'll likely have options to either recompile the dependencies with Cesium, or use them as-is via (automatic) .NET interop, if your use case requires that.

Can I still use native code (parts written in assembly)? If yes, how?

This is related to the previous question. Sooner or later, Cesium will get an interop model to load and call native libraries. So, if you can compile a DLL¹ from your assembly code, then you'll be able to call it.

There are no immediate plans to support asm blocks in Cesium, but when we will support them, then most likely we'll concentrate on CIL assembly and not some platform-dependent native assembly language. After all, one of the main Cesium motivations is code portability, and (AFAIK) there are no portable assembly variants.

We could make it pluggable, though, and allow the users to specify assembly translators they would like to use to process their asm blocks and somehow link them together into an executable, but all this sounds very complex, and currently there are no such plans.

Are the C integer types stored identical in memory when using cesium as they were with gcc?

Currently I believe they are (i.e. long is 64-bit), but we make no such guarantees. In the C world, there's no one-size-fits-all rule on what the integer sizes should be (practically, there are most common LP64 and LLP64 models, and according to that definition, .NET and by extension Cesium are LP64, as well as gcc). For now, we focus on .NET and thus chose the .NET type model (in particular, to make long in C# mean the same as long in C: a detail that some existing implementations deserted).

One fun extension I have in mind is to make long long 128-bit (#127), because why not :)

If you (or the maintainer of a library you use) want your C code to be portable, you should probably use fixed-size integer types like uint64_t, as defined by the C standard. For these types, Cesium will of course follow the standard.

Another problem you didn't mention is type layout and alignment. For now, we consider Cesium to use the .NET layout and alignment by default, but in general I'm not against compilation options that will change those (and even the integer sizes) if practically required.

Footnotes

1. I mean "a DLL" in a common sense: a dynamically-loadable library, not necessarily a Windows module. It can be .so or .dylib as well. Whatever the .NET runtime for a particular platform is able to load. ↩

[GitMensch]

OK, so for now looking at occil from OrangeC, please drop a note here when the state of any of those points change.

In the meantime - good luck and happy hacking!

[BadRyuner]

We could make it pluggable, though, and allow the users to specify assembly translators they would like to use to process their asm blocks and somehow link them together into an executable, but all this sounds very complex, and currently there are no such plans

You could add a thing like this: https://github.com/Hitmasu/InAsm 😉