[MonoAPI] Split type and function headers, add MONO_API_FUNCTION macro

[lambdageek]

The idea is that the function header can be included multiple times with
different definitions of MONO_API_FUNCTION in order to make it easier to
re-used the definitions for embedding the runtime in late-binding scenarios

Contributes to #64456

[lambdageek]

@joncham@vargaz Want to get your feedback before I do metadata/ and mini/.

@joncham I think this will work for Unity-Technologies#4

[lambdageek]

This one is ready for review, @vargaz

Went ahead and changed the metadata and jit headers too. Also renamed the jit header directory - this will eliminate the difference between how to include jit.h in-tree vs in an embedding scenario, which will simplify the test PR. Updated the runtime to #include <mono/jit/jit.h>.

[joncham]

@lambdageek one thing I just hit in my integration is calling convention. On 32-bit windows CoreCLR is built specifying STDCALL as the calling convention. This required me to decorate all my exported Mono functions with __cdecl. I think the current macro approach will let me do same, just FYI.

[lambdageek]

@lambdageek one thing I just hit in my integration is calling convention. On 32-bit windows CoreCLR is built specifying STDCALL as the calling convention. This required me to decorate all my exported Mono functions with __cdecl. I think the current macro approach will let me do same, just FYI.

@joncham, just so I'm clear, you'd do something like this, right?

extern"C" {
#defineMONO_API_FUNCTION(ret,name,args) typedefret (__cdecl * name##_type) args;
#include<mono/metadata/details/object-functions.h>
#undef MONO_API_FUNCTION
#defineMONO_API_FUNCTION(ret,name,args) static name##_type name;
#include<mono/metadata/details/object-functions.h>
#undef MONO_API_FUNCTION
staticvoidinit_functions()
{
HMODULE hModule = ...
#defineMONO_API_FUNCTION(ret,name,args) name = (name ##_type)GetProcAddress(hModule, #name );
#include<mono/metadata/details/object-functions.h>
#undef MONO_API_FUNCTION
}

[joncham]

@joncham, just so I'm clear, you'd do something like this, right?

Correct.

[akoeplinger]

nit: it would be nice to retain this warning in mono-private-unstable-types.h and mono-private-unstable-functions.h too.

[akoeplinger]

this will inadvertently install other files we put into these directories, e.g. README.md, right?
could we instead split jit_public_headers_base etc. into the normal and details/ .h files and install them separately here?

[lambdageek]

this will inadvertently install other files we put into these directories, e.g. README.md, right? could we instead split jit_public_headers_base etc. into the normal and details/ .h files and install them separately here?

Yea I think so. I would just use install(FILES) then, I think, right? I don't really know what i'm doing with cmake install rules.

[akoeplinger]

Yes that sounds good.

[am11]

We normally don't use install(DIRECTORY, @lambdageek. Elsewhere, we explicitly capture all the needed files in a variable, then use: install(FILES ${that_var} DESTINATION path/to/some/dir).

[akoeplinger]

We should also update the CODEOWNERS file.

[lambdageek]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[lambdageek]

I'm going to do a follow-up PR with a make one more slight tweak.

Instead of defining functions like this:

MONO_API_FUNCTION(MONO_APIMONO_RT_EXTERNAL_ONLYreturnType, mono_function_name, (MonoObject*arg1, MonoObject*arg2))

I'm going to pull the MONO_API part into the default definition of MONO_API_FUNCTION, and probably MONO_RT_EXTERNAL_ONLY into a new modifiers argument:

MONO_API_FUNCTION(MONO_RT_EXTERNAL_ONLY, returnType, mono_function_name, (MonoObject*arg1, MonoObject*arg2))

where we define the macro as:

#defineMONO_API_FUNCTION(modifiers, ret, name, args) MONO_API modifiers ret name args;

The issue is that MONO_API in C++ builds expands to extern "C", which is in an illegal place if you're using a MONO_API_FUNCTION to typedef a function pointer type.

I'm less sure about the modifiers part - currently MONO_RT_EXTERNAL_ONLY is the only one that we have and it expands to the empty string outside the runtime, so maybe it's not worth pulling it out. But it doesn't really belong with the return type, either. And there might be some other attributes that we might want in the future (e.g. for deprecation warnings) that different MONO_API_FUNCTION definitions might want to strip off.

FYI /cc @joncham

[lambdageek]

I ended up redefining MONO_API_FUNCTION on this PR. still with 3 arguments. 4 arguments where the 1st argument is mostly empty looked ugly (e.g. MONO_API_FUNCTION(,MonoObject *, mono_some_function, (MonoObject *arg1))) and MONO_RT_EXTERNAL_ONLY expands to empty outside the runtime build, so it didn't seem worth it just for that.

[lambdageek]

"CoreCLR Product Build windows arm64 " (checked and release) build failures are #65624 (comment)