Page MenuHomePhabricator

csharp: Revamp dotnet support
ClosedPublic

Authored by lauromoura on Aug 22 2019, 8:28 PM.

Details

Summary

Instead of building with a patched meson version, make use of custom
targets and generated csproj files so we can used upstream meson
normally.

This avoids digging into "non official" dotnet stuff like calling
the CSC.dll directly that the patched meson tried to do.

To enable, run meson with -Ddotnet=true.

Regarding source file dependencies, Meson has a limitation[1]
about generated artifacts being placed in subdirectories.

In order to correctly track these generated artifacts for dotnet, we
generated them in the same folder as the csproj file through
dotnet build -o.

Instead of installing the dll like we do for mono, a nupkg is generated
and installed in the same folder as the dll would be
(<prefix>/lib/x86_64-linux-gnu/efl-mono-1)

To avoid messing around with Nupkg caches, we reference the source
project for the library directly instead of the nupkg when building the
test suite.

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

Fixes T8168

Diff Detail

Repository
rEFL core/efl
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
lauromoura created this revision.Aug 22 2019, 8:28 PM
lauromoura requested review of this revision.Aug 22 2019, 8:28 PM

Tentative patch. Added DO_NOT_MERGE while we get feedback from @woohyun and @Jaehyun_Cho regarding this dotnet change.

Any chance we get this in for 1.23?

@lauromoura
After applying this patch, it seems that efl_sharp.dll is not installed.
efl_sharp.dll is created in efl/core/efl/build/src/bindings/mono/efl_sharp.dll but it is not installed in /usr/local/...

lauromoura updated this revision to Diff 24893.Sep 10 2019, 7:50 AM

Updated, now installing both the nupkg and the dll.

I thought about generating and installing the nupkg but it seems referencing the DLL directly in the csproj like the code below would be enough.

<ItemGroup>
  <Reference Include="Assembly">
          <HintPath>/opt/efl-mono/lib/x86_64-linux-gnu/efl-mono-1/efl_sharp.dll</HintPath>
  </Reference>
</ItemGroup>
Jaehyun_Cho accepted this revision.Sep 10 2019, 9:28 PM

@lauromoura
I cannot find a proper way to install Efl.Csharp.1.23.0.nupkg on Visual Studio Code on Ubuntu.
But that .nupkg can be installed Visual Studio on Windows.

Since .nupkg is alternative to .dll on Visual Studio on Windows, I think generating and installing .nupkg is also meaningful.
(although it seems that creating .nupkg in lib directory doesn't help Visual Studio)

I think the current version of this patch is good enough :)

This revision is now accepted and ready to land.Sep 10 2019, 9:28 PM

I added DO_NOT_MERGE as we are in freeze and this is quite a big change in the build files.

@lauromoura
I cannot find a proper way to install Efl.Csharp.1.23.0.nupkg on Visual Studio Code on Ubuntu.
But that .nupkg can be installed Visual Studio on Windows.

Is it working on windows? (It's been a long time since I last tested there)

Since .nupkg is alternative to .dll on Visual Studio on Windows, I think generating and installing .nupkg is also meaningful.
(although it seems that creating .nupkg in lib directory doesn't help Visual Studio)

We could create another task specific for nupkg to check if the package is properly created, documented, tested etc.

I think the current version of this patch is good enough :)

Nice. Waiting for @bu5hm4n comments on the meson side (no hurry, as this will be after the freeze)

lauromoura planned changes to this revision.Oct 2 2019, 3:02 PM

Needs rebase after the release.

lauromoura updated this revision to Diff 25882.Oct 2 2019, 8:43 PM

Rebase.

Also added a declaration of Efl.ObjectRealized using Efl.Object.NativeMethods as its NativeClass attribute. The hidden class test was failing in dotnet without it, as the class map when marshalling from C was not finding it.

This revision is now accepted and ready to land.Oct 2 2019, 8:43 PM
lauromoura updated this revision to Diff 25884.Oct 3 2019, 4:08 AM

Update with support for dotnet core 3.0

It will set the right netstandard/coreapp based on the dotnet executable version.

lauromoura updated this revision to Diff 26520.Tue, Oct 29, 1:53 PM

Rebase and update after D10337 added friendly assemblies

lauromoura updated this revision to Diff 26521.Tue, Oct 29, 2:07 PM

I put the wrong assembly name for mono...

This revision was automatically updated to reflect the committed changes.
YOhoho added a subscriber: YOhoho.Thu, Nov 7, 2:21 AM

@lauromoura
Is there any reason not to use csc directly?
csc has been available since mono 5.0.0 ( https://www.mono-project.com/docs/about-mono/releases/5.0.0/#c-compiler )

@lauromoura
Is there any reason not to use csc directly?
csc has been available since mono 5.0.0 ( https://www.mono-project.com/docs/about-mono/releases/5.0.0/#c-compiler )

Isn't generally csc mono's Roslyn-based compiler?

This patch focuses on building and running with the actual dotnet toolchain, making it easier to integrate stuff like StyleCop, detecting some bugs, etc.