DotNet Core 2.0 - Status Update

[David Naylor]

On Sunday, 24 September 2017 23:36:32 Russell Haley wrote:
> Hey,
> 
> *This is my understanding of what's going on and I am looking for
> Tomas or Karel to correct or clarify.
> 
> I've continued poking around on the build to little effect so far.
> Tomas has said there is an update to the official repository coming
> soon that runs for the most part on his 11-release instance. (I'm sure
> he will elaborate at some point).
> 
> Progress for Users:
> The ability to produce binaries that will allow people to compile and
> run applications is still a little ways out but there is a "first
> candidate" coming for the curious.
> 
> For "the curious":
> There are multiple repositories for DotNet Core but two main "halves"
> to any runtime: the native parts and the managed code parts. Right
> now, the native pieces build for Tomas. The managed code parts however
> require there to be an existing copy of the .Net Framework to build
> dotnet core 2.0. Because that doesn't exist on FreeBSD (and never
> will), there are currently three solutions:
> 
> - Build the managed parts on Windows
> - Build the managed parts on Linux
> - Build the managed parts on FreeBSD with mono (theoretical only)
> 
> >From what I understand, this bootstrap conundrum will always exist for
> 
> FreeBSD (except using a prior port to bootstrap the next one?). What I
> think needs to happen is we need to create a first version of the port
> that imports the managed code from a Windows or Linux repository. This
> would become a boot strap port that could be replaced once the DotNet
> Core team at Microsoft figure out a more permanent solution. Or not,
> and we always have a bootstrap package.  :P
> 
> The alternative is to work towards getting the managed parts to build
> in Mono and making mono a prerequisite to build. This would be a
> FreeBSD only solution, but could get some traction from the Mono team
> (now at Microsoft) and would be good for the FreeBSD mono port.

We could do what Mono does to bootstrap the managed code (i.e. monolite):
 1) Have a machine running a prior version of dotnet (say 2.0)
 2) Use existing dotnet (2.0) to compile managed code for new dotnet (say 2.1)
 3) Tarball the managed code and make available through FreeBSD's public 
distfiles infrastructure
 4) Update port's version of dotnet native code to new version (2.1)
 5) Use the tarball in step (3) to compile managed code in ports for new 
version (2.1)
This is mostly the same as your first suggestion, except we compile the 
managed code from a prior version for dotnet instead of using a different OS.  

I would, personally, prefer directly compiling the managed code with mono as a 
backup (say, if someone wants to bootstrap the process themselves).  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freebsd.org/pipermail/freebsd-mono/attachments/20170927/f35b7eac/attachment.sig>