Skimmed through all changes, but didn't run-test.

Meanwhile, the upstream accepted my patch: https://github.com/dotnet/runtime/pull/100731

The change looks fine but remember that maintainer timeouts don't work on Phab. You need to create a bugzilla PR for this.

• Add Patreon and Opencollective sites
• databases/sqlitebrowser: Add sponsorship information
• textproc/logseq: Add sponsorship information

It'd be great if you do that (and maybe also update the port to 8.0.3)

In D44560#1018480, @zirias wrote:

• It will expect dotnet installed in ${LOCALBASE}/share/dotnet while the port currently installs to ${LOCALBASE}/dotnet, is this intentional?

• Put sponsorship information into the resulting package via PKG_NOTES

I'm again not sure about post-install part. I think something should be patches in the runtime code to look in the location suitable for FreeBSD.

In D44509#1017272, @makc wrote:

Moreover, nothing in the ports tree needs plain cmake:env without dependency on cmake.

To make it less an abuse I'd name the feature something like enforce_aslr. So that it underlines the fact that enabling this feature will force ASLR setting for each port.

@vishwin is maintainer, but be aware that maintainer timeout rule doesn't affect Phab Diffs (regrettably), only Bugzilla PRs.

With our Linuxulator technology we might be actually able to run both Linux and FreeBSD binaries. I'll look into that.

Just realized that isn't an option anyways as these always have some native code stub that probably won't work on FreeBSD anyways, so sorry for this brainfart.

Ooh, you're right.

can be reproduced with the simplest possible helloworld project:

In FreeBSD the $LOCALBASE directory plays role of /usr, so from the FreeBSD perspective .NET is installed into a standard location and no pointer files are needed.

Do you have concrete steps that would allow to observe the problem when that file is missing?

Can you please elaborate a bit on what problem does this change solve?

@contact_shiori.com.br Sorry for taking this so long. If you still want to get this in and will maintain the port, I'll push it to the tree.

Can't agree with Daniel here. USES=cmake should be the most common case which is "depend on cmake executable and use it for configuring the project'. The cmake:build might be misleading - I'd think of it as the same as just cmake currently is.