Created attachment 232535 [details] lang/mono6/Makefile (updated for git submodule distinfo at GitHub) In the progress of trying to develop a port for omnisharp-roslyn[1] - this, as in order to contribute a port for omnisharp-roslyn, corresponding with a patch for Emacs and Ruby support for the Language Server Protocol (eglot, rubygem-solargraph) in ports[2] ... in order to build omnisharp-roslyn one must first have installed a usable dotnet SDK and mono, both, then to update the source tree for the 'cake'[3] build tool. Cake would then be used in lieu of msbuild for the omnisharp-roslyn build. In short, the 'dotnet' command would be used to ensure that the latest cake assemblies are installed, then mono would be used for running the cake assemblies. With Linux ABI emulation installed, loaded into the kernel, and enabled in the userspace filesystem for the build -- e.g using 'service linux onestart' -- it may be possible to simply retrieve a .NET SDK build of the appropraite version and extract under ${WRKSRC}/.dotnet/ then to run ${WRKSRC}/.dotnet/dotnet of that specific version ... lastly to use the a mono installed from under ports, for running the thusly-installed cake assemblies. The omnisharp-roslyn project's global.json could be used for determining the version that it requires for the .NET SDK. As this would be used only to install the assemblies for Cake, perhaps there may be some other way to accomplish this part - assuming a known master site is availabler for those assemblies. Then mono could be used to run nuget as under the cake build of omnisharp-roslyn, this to retrieve any needed nupkg files etc, before figuring out how to map this into a master sites configuration for ports. For this process, I'm afraid that the lang/mono port (mono version 5.10.1.57) may not be recent enough for the omnisharp-roslyn build. So, I'd tried to build lang/mono6.8. The build failed, in the mono external for boringssl. Subsequently, I took a look at the Mono master site[4]. The last mono version distributed there (mono version 6.12.0.122) was published on 22 February, 2021. The most recent mono version at the Mono github repository[5] is 6.12.0.173, published this month, on 17 February, 2022[6]. The tagged Mono releases at GitHub have not been populated with the contents of submodule directories. In the attached Makefile, there's one methdology developed for working around this. It may be nono-trivial to update for subsequent Mono revisions but perhaps there can be some tooling developed for that. The attached Makefile may be of use for developing a new lang/mono6 port. This port could be updated for any later Mono 6 revisions, without the port being bound to a minor version of the Mono 6 release, such as with mono 6.8 With the attached Makefile as lang/mono6/Makefile, I've managed to at least get it to run 'make makesum' and 'make extract'. I'll take a look at the patches shortly. I'll also attach the locally generated distinfo file, for information purposes. I hope it may be possible to develop a more up-to-date port for Mono 6. I thought it might simply be useful to share this work-in-porgress Makefile for a lang/mono6 as well as the rationale for it in this single instance of port development [1] https://github.com/OmniSharp/omnisharp-roslyn/ [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262610 [3] https://cakebuild.net/docs/running-builds/runners/dotnet-tool [4] https://download.mono-project.com/sources/mono/ [5] https://github.com/mono/mono [6] https://github.com/mono/mono/tree/mono-6.12.0.173/
Created attachment 232537 [details] lang/mono6/distinfo distinfo file for mono external/*/ submodules via GitHub This does not address any possible instances of recursive submodules under mono
Created attachment 232538 [details] updated lang/mono6/Makefile for mono and submodules at GitHub an updated lang/mono6/Makefile, using GH_SUBDIR for handling the post-extract in each submodule
It looks like all of the boringssl patches used in the lang/mono6.8 build have been incorporated upstream, in the boringssl used for mono 6.12.0.173. The patch update has been fairly straightforward. I'm testing the build, now, will hopefully have a unified diff available here sometime before the end of the week. For this build from github, I've updated the USES=autoreconf decl from lang/mono6.8 to use autoreconf:build. Running autoreconf before autogen in mono 6.12.0.173, it was failing on a missing mono/mini/Makefile.am. This file is generated by mono's autogen.sh now. Mono still needs autoconf in the build, however. With only those changes, the build's running alright up to the mono-mono-6.12.0.173/mono/ subdirs. bdwgc built OK. Hopefully Mono's llvm and the rest of the externals will work out
It was actually during the brotli build that the lang/mono6.8 build was failing here. Unfortunately, that's still happening in this newere mono 6 build, within the mono corefx external ~~~~ ../../external/corefx/src/Native/AnyOS/brotli/enc/dictionary_hash.c:16:1: error: unknown type name 'BROTLI_INTERNAL' BROTLI_INTERNAL const uint16_t kStaticDictionaryHash[32768] = { ^ ../../external/corefx/src/Native/AnyOS/brotli/enc/dictionary_hash.c:16:31: error: expected ';' after top level declarator BROTLI_INTERNAL const uint16_t kStaticDictionaryHash[32768] = { ^ ; 2 errors generated. gmake[5]: *** [Makefile:2210: ../../external/corefx/src/Native/AnyOS/brotli/enc/libmono_native_la-dictionary_hash.lo] Error 1 ~~~~ Maybe there's a missing include directive, such that BROTLI_INTERNAL is not being defined in those files? while it's defined in a header under the brotli src.
That build failure may have been due to using ${CC} -E as CPP in the build. Trying a build with clang-cpp instead, as CPP for this lang/mono6 port This is with clang 13 from FreeBSD 12.3
It's possible to use a newer brotli source tree for under the corefx external. It needs an additional distfile, some post-extract tooling e.g using COPYTREE_SHARE, and a patch on Mono's mono/native/Makefile.am to ensure that all of the brotli files under the corefx external are built. This may be portable to the existing lang/mono6.8 port. I'll try to post a unified diff for the makefile and updated patches, and other port files, after some more build testing. The ostensible lang/mono6 port build has not failed out in the corefx section at least. It's being tested under local build and poudriere, on a laptop.
The build failed under the local build. It's still continuing under the poudriere build for the moment. ~~~~ Directory does not exist: '/usr/ports/lang/mono6/work/mono-mono-6.12.0.173/external/api-doc-tools/external/Lucene.Net.Light/src/core/Util' Directory does not exist: '/usr/ports/lang/mono6/work/mono-mono-6.12.0.173/external/api-doc-tools/external/Lucene.Net.Light/src/core/Util' Directory does not exist: '/usr/ports/lang/mono6/work/mono-mono-6.12.0.173/external/api-doc-tools/external/Lucene.Net.Light/src/core/Util' CSC [net_4_x-unix] WindowsBase.dll // gensources produced 425 error(s) and a set of 48 filename(s) // Invoked with '/usr/ports/lang/mono6/work/mono-mono-6.12.0.173/mcs/class/lib/build/gensources.exe --strict --platformsdir:./../../build ../../build/deps/unix_net_4_x\ __monodoc.dll.sources monodoc.dll unix net_4_x' // Working directory was '/usr/ports/lang/mono6/work/mono-mono-6.12.0.173/mcs/class/monodoc' gmake[12]: *** No rule to make target '../../build/deps/unix_net_4_x__monodoc.dll.sources', needed by '../../build/deps/unix_net_4_x__monodoc.dll.response'. Stop. gmake[11]: *** [../../build/rules.make:220: do-all] Error 2 gmake[10]: *** [../build/rules.make:258: monodoc] Error 2 gmake[10]: *** Waiting for unfinished jobs.... Microsoft.Build.Utilities/TaskLoggingHelper.cs(39,16): warning CS0169: The field 'TaskLoggingHelper.buildEngine' is never used System.Transactions/CommittableTransaction.cs(62,8): warning CS0252: Possible unintended reference comparison; to get a value comparison, cast the left hand side to ty\ pe 'Transaction' System.Transactions/TransactionManager.cs(84,4): warning CS0067: The event 'TransactionManager.DistributedTransactionStarted' is never used System.Windows/Size.cs(78,9): warning CS0168: The variable 'value' is declared but never used gmake[9]: *** [../build/rules.make:241: all-recursive] Error 1 gmake[8]: *** [build/rules.make:241: all-recursive] Error 1 gmake[7]: *** [Makefile:58: profile-do--net_4_x--all] Error 2 gmake[6]: *** [Makefile:54: profiles-do--all] Error 2 gmake[5]: *** [Makefile:708: all-mcs] Error 2 gmake[5]: Leaving directory '/usr/ports/lang/mono6/work/mono-mono-6.12.0.173/runtime' gmake[4]: *** [Makefile:601: all-recursive] Error 1 gmake[4]: Leaving directory '/usr/ports/lang/mono6/work/mono-mono-6.12.0.173' gmake[3]: *** [Makefile:529: all] Error 2 ~~~~ The api-doc-tools external is using the same revision as for that Mono version's external/api-doc-tools submodule. iirc Lucene.Net.Light source tree was copied from the ASF's Lucene.net project, at some point. Maybe there's a way to prevent the build from entering that section.
Will try the build under --with-mcs-docs=no
Created attachment 232541 [details] unified diff for lang/mono6 addition and update to lang/Makefile This new lang/mono6 port uses what may be the last available mono6 release with all submodules bundled in the same distfile. The port uses Google's upstream brotli at the latest version in ports, to update the brotli used under the mono corefx external. This update is accomplished firstly with an additional distfile and scripting in post-extract, to copy a subset of the brotli source files in a compatible location under the mono corefx external. The update is lastly accomplished with an initial patch for adduing a subst flag, then some scripting in post-patch, as to update a Makefile.am. This Makefile.am would provide a list of the brotli source files for the build. For the monolite build option, the monolite distname and version have been updated to match with the updated distsrc. There are newer Mono 6 releases available at Github. However, in order to provide those via a port build in any initial port or in any subsequent updates, it may need some additional tooling both to parse a set of recursive submodule references and to add those to some place where they can be pulled into a port makefile, as static declrations for some Mono release version. The build failrues I was seeing with the source code from github may have due it being built wil only a first-level, non-recursive set of submodule distfiles. If perhaps not all of the recursive submodules in Mono would be used for every build, maybe some scripting with filemon could serve to determine what externals/submodules are actually being used, thus which ones to keep updated for a mono-git port. The port contributed here builds succesfully. It may need additional testing, for the quality of the build itself.
This mono 6 release may need a newer msbuild. The recent msbuild releases from the Mono msbuild fork have begun using install-dotnet.sh. This might need a separate bug tracker item For the msbuild update, it may be feasible to use a Linux dotnet for some purposes in the build. For the Linux emulation to be available and configured with appropriate mount points, that would entail some requirements for the system, however. That may usually may be addressed with e.g 'service linux onestart'. Due to the quirks of pathname handling under the Linux ABI emulation, it might also need something like a nullfs mount for the ports tree e.g to an erfect: `mount_nullfs ${PORTSDIR} ${LINUXBASE}${PORTSDIR}`. It certainly becomes a less succinct kind of build, then. I'll try to see if the msbuild support for this Mono release can be worked out with the Linux ABI emulation for the Linux dotnet SDK and runtime bundles, under a ports build. I'm not certain if the scripting for the linux filesystem support could be easily addressed under ports.
Instead of a new port can you provide a patch against mono6.8? thanks.
Just watching this as a bystander who would be very much interested in having a working very recent mono (and dotnet core) for my Unreal Engine 5 "port" (not in the ports tree). I noticed that in the original post there was a mention of 6.12.0.122 being the latest on the mono website, but that would apparently be incorrect. 6.12.0.173 is in the 'preview' [1] subdirectory. There's even a nightly build directory [2] which contains versions up to 6.13.0.1230. I didn't check much of the code but I'm guessing that this would make the port less complicated again. btw. +1 vote for mono6, but it might be interesting to keep mono 6.8 since there are a few other packages depending on it [1] https://download.mono-project.com/sources/mono/preview/ [2] https://download.mono-project.com/sources/mono/nightly/
And remove py-pillow from RUN_DEPENDS. py-pillow is completely unnecessary to run anything under mono. It's a lot of unnecessary dependencies. py-pillow only for mono-heapviz script. "Generate a heap visualization for SGen from the heap dump written by mono if the MONO_GC_DEBUG is set to something like heap-dump=/path/to/file."
Created attachment 243916 [details] Update mono6.8 to mono6.12 This patch updates in tree Mono port from 6.8 to 6.12. It is based on Sean Champ's original patch. I have only tested the build with poudriere-testport on 14-CURRENT.
Created attachment 243917 [details] Update mono6.8 to mono6.12 Try again. This time include deletions of mono6.8 in the diff.
Created attachment 243918 [details] Update mono6.8 to mono6.12 Fix patch in files/ Remove local patch for python
A change log: https://www.mono-project.com/docs/about-mono/releases/6.12.0/
Better patch for Ninja build at bug #272986
Created attachment 243959 [details] Update mono6.8 to mono6.12 Duplicate autoreconf and ${CONFIGURE_SCRIPT} patch from bug #272986
^Triage: reset Assignee after ports 4553130a9c53.
^Triage: reset Assignee after ports c59052ead113. (ignore previous comment, it referenced bogus commit)