Page MenuHomeFreeBSD

[GSoC 2018] Porting of .NET Core Runtime, SDK, and PowerShell
Needs ReviewPublic

Authored by mateus_mateus.tech on Aug 14 2018, 3:56 AM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Apr 18, 1:55 PM
Unknown Object (File)
Fri, Apr 5, 2:26 AM
Unknown Object (File)
Fri, Apr 5, 12:30 AM
Unknown Object (File)
Feb 21 2024, 7:01 PM
Unknown Object (File)
Feb 18 2024, 9:31 AM
Unknown Object (File)
Feb 11 2024, 11:18 AM
Unknown Object (File)
Jan 29 2024, 11:59 PM
Unknown Object (File)
Jan 3 2024, 3:01 AM

Details

Reviewers
dbn
theraven
feld
Summary

As part of my Google Summer of Code 2018 project, these are the results of the work I did on porting the .NET Core runtime, SDK, and PowerShell Core to FreeBSD.

The runtime includes all needed resources to run existing .NET Core application on the platform, the SDK contains tools to build applications, and the PowerShell port has these last two as dependencies to build and run PowerShell on FreeBSD. These are the first results on the efforts to bring .NET Core to FreeBSD, which are the results of the past three months of work during GSoC.

As it's known, .NET Core contains both native and managed components. However, currently the managed components need to be built on a Linux machine because of the build tools support not yet being fully available on FreeBSD, even with Linux emulation. Therefore, the .NET ports only support the build of native components, managed ones are downloaded pre-compiled.

As for PowerShell, the ported .NET Core SDK should be enough to fully build it on the machine from the port.

These are some important links regarding the work done during GSoC:

Repositories:

General links and discussion threads:

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

[GSoC 2018] Changed MASTER_SITES in the Makefiles to FreeBSD CDN.

devel/dotnet-sdk/Makefile
8

That is absolutel wrong. This should be LOCAL/dbn/dotnet:sdk

21

You MUST NOT use GH_TUPLE for the default distfile, use:

GH_ACCOUNT=dotnet
GH_PROJECT=core-setup
GH_TAGNAME=2ad3de5
23

You MUST add a comment about why you add MAKE_JOBS_UNSAFE.

devel/dotnet-sdk/pkg-message
24

There should be one.

devel/dotnet/Makefile
8

LOCAL/dbn/dotnet:managed

30โ€“31

Wrong place in the Makefile. See Chapter 15. Order of Variables in Port Makefiles.

34โ€“35

Wrong place in the Makefile. See Chapter 15. Order of Variables in Port Makefiles.

37

Do not use GH_TUPLE for the default distfile, split it up with GH_ACCOUNT/PROJECT/TAGNAME.

41

Add a comment why.

devel/dotnet/pkg-message
24

There should be one.

shells/powershell/Makefile
44

Why.

shells/powershell/pkg-message
25

There should be one.

shells/powershell/pkg-plist
43

There should be one.

[GSoC 2018] Update related to changes according to @mat's reviews

May I suggest you add "test" targets to the ports?

This is a rather fomplex set of ports and we want to be able to be testing frequently.
If many test still fail it may be desirable to watch the test target atound a #ifdef. MAINTAINER_MODE .

devel/dotnet-sdk/Makefile
1

These days we no longer include the created by tag.

4

This port conflicts with linux-dotnet-sdk*

devel/dotnet-sdk/pkg-plist
1

It would be useful to substitute SDK_VERSION in the pkg-plist (see lang/linux-dotnet-sdk for an example)

666

Strange make check-plist shows this entry missing. I think you are missing a new line here.

devel/dotnet/Makefile
4

This port conflicts with linux-dotnet*

21

Missing dependency! We have llvm38 in ports, but I think the best one to use is llvm60.

23

This seems to be picking up base libgssapi_krb5.so instead of port libgssapi_krb5.so

28

You need USES=ssl. Please make sure you have DEVELOPER=yes set in /etc/make.conf

60

If you instead ${ARCH:S/i386/x86/:S/amd64/x64/} then you can avoid needing to bring in bsd.port.pre.mk

66

I think you need to add ${SETENV} LLVM_HOME=${LOCALBASE}/llvm60 before calling ./build.sh: lldbplugin hardcodes FreeBSD paths to clang 3.8 and 3.9. This is incorrect as it

  1. Ignores what version of clang we pass on the command line; and
  2. Does not work when we switch to a newer version of clang

Setting LLVM_HOME avoids the above problems.

devel/dotnet/pkg-plist
5

Please also sub the RUNTIME_VERSION

240

When I compiled this, this wasn't in STAGEDIR. (I did need to adjust a few things to work with clang6.0 - not sure if that broke anything).

feld added a subscriber: feld.

Is there something I can do to help move this forward?

So, it's 2020 now (HNY), what's the current state of affairs?

devel/dotnet-sdk/Makefile
1

It had become optional, but I don't see the reason why Mateus should not be allowed to include his name there. After all, this is quite a substantial work to warrant explicit attribution.

devel/dotnet/Makefile
21

Probably had to be revised again, those LLVM dependencies are fast moving targets, quite unfortunately.

It probably makes sense to update the dotnet-sdk port once again since upstream has also
created new build instructions for 3.1.103 on FreeBSD.

https://github.com/jasonpugsley/core-sdk/wiki/Build-.NET-SDK-3.1.103-for-FreeBSD

swills removed a subscriber: swills.
swills added a subscriber: swills.