Page MenuHomePhabricator

Modify meson project to find and use dotnet csc correctly
Open, Incoming QueuePublic

Description

dotnet core uses 'dotnet' to load an run applications (the same way that mono uses 'mono'), however, it uses the same thing for its own compiler, which is a DLL in sdk/{sdk-version}/Roslyn/bincore

Since it is not in the PATH, there should be a way to find the compiler by meson and a way to decide which compiler to use when both (mono and dotnet) are found.

This bug is actually in meson, but impacts EFL.

There is a couple of working meson patches in https://github.com/lauromoura/meson/tree/dotnet-core. It needs to be polished (aka better tested) before updating the pull request but it allows one to select dotnet (when D8069 lands) by setting CSC=dotnet when invoking meson (Alternatively, probably using a host description file should work too).

Have you sent this through CI for meson ? it is very good and catches a lot of toubles.

I've been trying another approach, as dotnet seems to be designed to be used through its regular cli commands (dotnet build, dotnet run, dotnet pack, etc.).

Instead of trying to call csc.dll directly with a patched meson, in the branch devs/lauromoura/dotnet-upstream it uses configure_files to generate custom .csproj files and custom_targets to call dotnet pack, dotnet build, etc, all using upstream meson.

There are some rough edges regarding distribution, correctly naming the target outputs, respecting @beta, etc. But in its current stage I managed to run the test suite correctly.

PS: In the branch there is also a commit to create a nupkg package for mono-based builds.

Mhm - i have not looked in detail, but to me this seems like this breaks dependency tracking of the .cs files ? I am also a little bit worried how versioning etc. of the project files the binaries etc. will impact that ...

Mhm - i have not looked in detail, but to me this seems like this breaks dependency tracking of the .cs files ? I a

I think we could deal with this using the input parameter for custom_target. As I understand, meson uses it just to track whether it should re-run this target and to provide it to the command it will execute through the @INPUT@ metavar. I'll do some tests and review this part.

also a little bit worried how versioning etc. of the project files the binaries etc. will impact that ...

Currently the Mono dlls we generate lack any form of versioning. For the dotnet approach, I'm using meson.project_version().

As for loading the correct native EFL libraries, it follows the current mono scheme of searching through LD_LIBRARY_PATH, etc, as it uses the same dlopen scheme under the covers (inside NativeModule.cs/FunctionWrapper.cs)

I've updated the branch with some improvements:

  • Respect -Dmono-beta
  • Track dependencies correctly (using the same input as the mono libs)
    • For this I had to generate both the binding nupkg and the test suite (now a dll) in the same directory as their csproj file. Meson has issues[1] regarding output artifacts in subfolders.
  • Install nupkg to the same folder as the mono dll is installed.

Before submitting for revision, I'm doing some tests regarding cached packages and using an installed version of the nupkg, both from a manual dotnet project and from monodevelop (Well, the latter seems to be complaining about dotnet support in my install here, even without our packages).

@woohyun would behavior of building with dotnet and upstream meson plus installing a nupkg have any issues for Tizen ?

[1] https://github.com/mesonbuild/meson/issues/2320

Still having some issues regarding package caching. Nuget seems too conservative to restore a recently built Efl.Csharp package, even with restore -f --no-cache, etc. Just works after cleaning the package registry.

Will try changing to use only the dll in tree and leave the nupkg to be built when installing.