DotNet Core 2.0 - Status Update

[Tomas Weinfurt]

Yes, your assessment seems right David. 
This is similar to building compiler. You need something to compile it with. 
C# compiler Roslyn is written in c#. 
To break the loop, you have set of reference bits – previous version, mono or something else. 
We will still probably need precompiled assemblies in order to run Roslyn and other tools.

I’ve been trying to hack up “previous” version for FreeBSD so at least people can build and start working on fixes.
Fact that code builds does not mean it is ready. I can build and run “hello world” but running msbuild kills runtime.
Many tests are failing in corefx. (don’t know about coreclr and other repos yet) 
I think there is long way before we can call it ready for preview. 

The build from beginning is not specific to FreeBSD.
To add to the list: - Build the managed parts on FreeBSD with Linux/OSX/Windows version (theoretical only)
There may be more than one answer. It may be handy if previous version exists – for people who want to just hack on single repo and fix a bug. 
Building everything from scratch can be complicated and tedious. But I think the path should exist and be scriptable. 

Tomas

On 9/27/17, 12:15 PM, "David Naylor" <owner-freebsd-mono at freebsd.org on behalf of naylor.b.david at gmail.com> wrote:

    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).