Make it easier to link Koka code from an existing project

[MackNZ]

I attempted to use Koka with SDL3 on an AMD64 Mac. Some platforms apparently don't use main as a program entry point, and SDL3 uses C macros to hide those platform differences. When building an executable, Koka seemed to want a main function in a .kk file.

I wrote a minimal one, attempting to inline the SDL macro from a C file various ways, but based on the most sensible of the errors, the Koka compiler seems to actually parse the C function signature rather than blindly accepting it. Since platform entry functions don't have a Koka context parameter at the end of their signatures, I gave up on this approach.

I then attempted to have the Koka compiler build a library and link it myself to a C file with the SDL3 main macro. This turned out to be complex. A bunch of object files I didn't directly use got outputted in the build folder, and they are dependent on kklib and mimalloc. As far as I can tell, kklib and mimalloc aren't prebuilt for the platform as .a files. There does seem to be a CMakelists.txt file in the kklib directory which would make building a bit less painful for people using CMake.

Precompiling kklib and mimalloc to archive files, and having a command spit out linker dependency flags for a Koka library would make it easier to integrate Koka into existing projects.

[daanx]

I agree; I'll look into making it easier to get a link command. Running with -v3 actually shows the full c-compiler link command. However, in your case, would it work if you could specify another name for the main function that Koka generates? (and then use extern import to include your own C code that contains the real main needed by SDL3?)