<div dir="ltr">Hi Guys,<div><br></div><div>I took it upon myself to try and get a build up and running on Appveyor yesterday. Please have a look at <a href="https://github.com/mika76/mono">https://github.com/mika76/mono</a> and <a href="https://ci.appveyor.com/project/mmihajlovic/mono">https://ci.appveyor.com/project/mmihajlovic/mono</a> - so far the only thing I've edited is the appveyor.yml file and the actual a[[veyor settings. </div><div><br></div><div>At the moment it is installing cygwin and packages and running the visual studio msbuild file - which seems not to work - it fails with "compiler out of heap space" error.</div><div><br></div><div>If the msbuild does not pan out, the cygwin build can always be attempted as well.</div><div><br></div><div>If anybody wants to help, let me know and I'll make you a contributor on the repository.</div><div><br></div><div>Cheers,</div><div>Mladen</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 17 October 2014 08:46, Alex J Lennon <span dir="ltr"><<a href="mailto:ajlennon@dynamicdevices.co.uk" target="_blank">ajlennon@dynamicdevices.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    Hi Jonathan,<br>
    <br>
    Thanks for taking the time to provide the background.<br>
    <br>
    I understand/agree that facilitating development on Windows is a
    complex task. I've seen some of the emails over time and can well
    imagine it's complex and invasive to the existing build system.
    People start the work, but I''ve not seen anything come out of it.<br>
    <br>
    If I take my scope as something much simpler, which is just to
    facilitate building Mono on Windows from scratch, on a vanilla
    Windows platform, perhaps defined as Windows 7/8.1 x32/x64 or
    whatever, then I think that's much more achievable.<br>
    <br>
    I have been looking at this since 3.4.0 and the main issues I have
    encountered were having the right dependencies, idiosyncracies of
    the build tools, and issues with releases such as missing
    files/problems with Cygwin headers.<br>
    <br>
    Perhaps very few of us are fit for purpose when it comes to actually
    _contributing_ to Mono, but I can well understand that the first
    step an OpenSource developer wants to make is to compile a project
    from source and run up the results. <br>
    <br>
    I can also understand the frustration when you've spent a couple of
    days on this and just keep encountering problems. People can then
    give up in frustration.<br>
    <br>
    Even the longest journey begins with a single step and it strikes me
    that it would be a useful thing to facilitate newbies building on
    Windows to get them going on that journey, even if that's just by
    documenting issues they will encounter.<br>
    <br>
    The emails I get from individuals show me that when they do have the
    information they need to build Mono, and how to work around the
    gotchas, then they can do it with relative ease.<br>
    <br>
    <div class="gmail_extra">>- it's an amalgam of tools, which
      constantly update. There was never an easy way to duplicate a
      working setup from one machine to the next</div>
    <br>
    I agree, but that's an issue with any complex software project with
    build dependencies surely? I work with Yocto Embedded Linux builds
    and I can tell you that it's even more difficult there, but they
    manage it extremely well.<br>
    <br>
    To address this seems to me a matter of understanding/documenting
    the dependencies and, where necessary, defining the require versions
    of those dependencies to ensure a build works in a controlled
    manner.<br>
    <br>
    I am making an assumption that the dependencies are all on Cygwin
    (are there any others?). If so then it should be relatively
    straightforward to define the version of Cygwin to use and/or pull
    down specific versioned packages.<br>
    <br>
    It was suggested to me that a setup script that pulled down
    appropriate dependencies would be useful, and I agree. I have been
    meaning to do something on that as I think it is straightforward but
    haven't yet had the time.<br>
    <br>
    If this was to be in place do you think there would be any other
    toolchain issues that would need consideration?<br>
    <br>
    <div class="gmail_extra">>This was done with cygwin and was
      packaged by an additional installer step. The installer step was
      never very transparent so I can't comment on that. <br>
    </div>
    <br>
    Somebody somewhere must have been building the Windows installer, at
    least up until 3.2.3. I believe it would be helpful if somebody
    could take time to explain how this works or just provide the
    automation to build the installer.<br>
    <br>
    When we execute the 'make install' step what results on Windows is
    missing key files such as 'mono.exe' and instead has Linux stubs
    such as 'mono' which causes problems. I would like to understand how
    the install<br>
    step is supposed to work and to try to fix it instead of having to
    manually fix it up each time. Similarly I would like to be able to
    generate a non-official installer in the same way as the official
    installer is built, which at least <br>
    people could then use in the absence of an official installer.<br>
    <br>
    <div class="gmail_extra">> given the size and complexity of the
      mono build and tests, it was generally not robust. Especially for
      continuous and automated usage</div>
    <div class="gmail_extra"><br>
      My experience is that once the issues with any given release are
      addressed then it builds reliably. Master is of course a different
      beast but I am not looking at supporting a build from an arbitrary
      commit here.<br>
      <br>
      >- it was slow. Slow as in hours on Windows vs minutes on Linux</div>
    <div class="gmail_extra"><br>
      Yes, my guess is that it's perhaps related to forking on Windows
      under Cygwin but who knows.<br>
      <br>
      It would be nice to have a faster build but, for example, building
      a Yocto image can take many, many hours. (And don't get me started
      on WindowsCE...) I think people can live with this if it actually
      builds for them.<br>
      <br>
    </div>
    To me a first pass at needed actions are:<br>
    <br>
    - define one or more supported Windows build host platforms.<br>
    - take the latest Mono 3.10.0 release and create an installer script
    for versioned build dependencies<br>
    - create a simple build script and test script<br>
    - understand how the packaging step works and automate this<br>
    <br>
    - fix issues with installation of Mono files that aren't currently
    correct under Windows (e.g. mono 3.8.0 mono.exe, perhaps fixed in
    3.10.0)  <br>
    - fix issues with needing to change Cygwin headers for the compile
    to work.<br>
    <br>
    - setup a CI system building and reporting for master.<br>
    <br>
    Ideally, as I've said earlier, there would be some buy-in from
    whomever makes decisions on making a release, that before that
    release it made it should at least build cleanly on Windows.<br>
    <br>
    Cheers,<br>
    <br>
    Alex<br>
      <br>
    <div>On 17/10/2014 03:21, Jonathan Chambers
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">Hello,
        <div><br>
        </div>
        <div>I was maintaining the Visual Studio solution for the
          runtime and doing Windows development for a while but haven't
          kept up for a number of years now. We've had a number of
          "build mono on Windows" discussions over the years and various
          attempts at improving it. Breaking the discussion into two
          pieces:</div>
        <div><br>
        </div>
        <div>Release/Install/CI for Windows</div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">This was done with cygwin and was
          packaged by an additional installer step. The installer step
          was never very transparent so I can't comment on that. </div>
        <div class="gmail_extra">As for cygwin, the main issues were:</div>
        <div class="gmail_extra">- it's an amalgam of tools, which
          constantly update. There was never an easy way to duplicate a
          working setup from one machine to the next</div>
        <div class="gmail_extra">- given the size and complexity of the
          mono build and tests, it was generally not robust. Especially
          for continuous and automated usage</div>
        <div class="gmail_extra">- it was slow. Slow as in hours on
          Windows vs minutes on Linux</div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">Developing on Windows</div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">As for actually developing mono on
          Windows, the main issue was that you could not easily use
          Visual Studio to develop mono. The VS support for the runtime
          was put together long ago as a way to develop/debug, but it
          still required the full cygwin build to configure everything,
          build the class libraries, and run the tests. Even if one was
          brave enough to work in this setup, iteration time was slow
          (see above). Miguel and others made efforts to build
          everything using MSBuild but nothing quite materialized for a
          variety of reasons.</div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">All that to say, if you just want to
          get the Windows support back to where it was a few years ago
          via cygwin it can probably be done in a few developer weeks.
          If you actually want to improve the Windows development story,
          allowing for actual development and usage of Windows tools
          like Visual Studio it's much more work. I'd love for the
          latter to happen, but it's would take a lot of effort and
          coordination. Effort like improving xbuild where needed if
          msbuild is the build mechanism of choice. Coordination like
          making sure any work done didn't harm other platforms. </div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">- Jonathan</div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Thu, Oct 16, 2014 at 2:16 PM, Alex
            J Lennon <span dir="ltr"><<a href="mailto:ajlennon@dynamicdevices.co.uk" target="_blank">ajlennon@dynamicdevices.co.uk</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>
                On 16/10/2014 16:58, Bryan Crotaz wrote:<br>
                > What's the estimation of effort required to get
                mono buildable in<br>
                > windows and debuggable in VS? 6 man months? 18 man
                months?<br>
                ><br>
                > I don't have time to donate but I'd be happy to put
                some money in a<br>
                > pot with some of you to hire someone to work on
                this full time. Feels<br>
                > like a concerted full time effort would bear more
                fruit than<br>
                > occasional toe-dips in the water.<br>
                <br>
              </span>Bryan,<br>
              <br>
              fwiw - and this is merely a view from a bystander - I
              don't think it<br>
              would take a lot to address the Windows build itself
              today.<br>
              <br>
              Mono does build on Windows, but it doesn't "just work" as
              people tend to<br>
              expect nowadays. It needs some stream-lining imho with
              some setup script<br>
              automation or similar for newbies. There are also some
              missing links in<br>
              how an official Windows release is created versus using
              make, as we end<br>
              up with missing files on install (or I am
              misunderstanding  something<br>
              that needs doing, which in itself would be a documentation
              issue).<br>
              <br>
              To me this isn't a code issue so much as an ownership and
              release<br>
              management issue. I recognise there is a cost to that and
              there has to<br>
              be an ROI for that cost to be worth bearing.<br>
              <br>
              Releases are made with broken Window builds as Vincent
              says. So imho<br>
              it's a dead work "fixing" master at any given time as it
              will just<br>
              become broken again, although some basic setup scripting
              to pull down<br>
              Cygwin, dependencies, to get the installation step working
              and such<br>
              would help people to get going, I feel.<br>
              <br>
              What's more relevant, I believe, is a maintainer who has
              committed to<br>
              Windows build testing and patching prior to an  offical
              release of Mono,<br>
              a buy-in from other release maintainers that this is worth
              doing (or<br>
              what's the point?), and perhaps some CI running the Mono
              tests in the<br>
              background.<br>
              <br>
              Just my 4 cents,<br>
              <br>
              Alex<br>
              <div>
                <div>_______________________________________________<br>
                  Mono-devel-list mailing list<br>
                  <a href="mailto:Mono-devel-list@lists.ximian.com" target="_blank">Mono-devel-list@lists.ximian.com</a><br>
                  <a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
                </div>
              </div>
            </blockquote>
          </div>
          <br><span class="HOEnZb"><font color="#888888">
        </font></span></div><span class="HOEnZb"><font color="#888888">
      </font></span></div><span class="HOEnZb"><font color="#888888">
    </font></span></blockquote><span class="HOEnZb"><font color="#888888">
    <br>
    <div>-- <br>
      <div>
        <p style="font-family:Helvetica,Arial,sans-serif;font-size:10px;line-height:12px"><a href="http://www.dynamicdevices.co.uk/" target="_blank"><img src="cid:part4.05070501.07010702@dynamicdevices.co.uk" alt="Dynamic Devices Ltd" border="0"></a></p>
        <p style="font-family:Helvetica,Arial,sans-serif;font-size:10px;line-height:12px;color:rgb(153,153,153)"><span style="font-weight:bold">Alex
            J Lennon</span> <span>/</span> <span style="color:#999">Director</span><br>
          <span style="color:#999">1
            Queensway, Liverpool L22 4RA</span> </p>
        <p style="font-family:Helvetica,Arial,sans-serif;font-size:10px;line-height:12px"> <span style="color:#999">mobile: <a href="tel:%2B44%20%280%297956%20668178" value="+447956668178" target="_blank">+44 (0)7956 668178</a></span>
          <span style="color:#999">landline:
            <a href="tel:%2B44%20%280%291513%20241374" value="+441513241374" target="_blank">+44 (0)1513 241374</a></span> <br>
          <br>
        </p>
        <p style="font-size:10px;line-height:12px;font-family:Helvetica,Arial,sans-serif"> <a href="http://www.linkedin.com/in/alexjlennon" target="_blank"><img src="cid:part6.04060409.04080201@dynamicdevices.co.uk" alt="Linkedin"></a> <a><img src="cid:part8.09070401.09070108@dynamicdevices.co.uk" alt="Skype"></a></p>
        <p style="font-family:Helvetica,Arial,sans-serif;color:rgb(153,153,153);font-size:9px;line-height:12px;width:25%">This e-mail message
          may contain confidential or legally privileged information and
          is intended only for the use of the intended recipient(s). Any
          unauthorized disclosure, dissemination, distribution, copying
          or the taking of any action in reliance on the information
          herein is prohibited. E-mails are not secure and cannot be
          guaranteed to be error free as they can be intercepted,
          amended, or contain viruses. Anyone who communicates with us
          by e-mail is deemed to have accepted these risks. Company Name
          is not responsible for errors or omissions in this message and
          denies any responsibility for any damage arising from the use
          of e-mail. Any opinion and other statement contained in this
          message and any attachment are solely those of the author and
          do not necessarily represent those of the company.</p>
      </div>
    </div>
  </font></span></div>

<br>_______________________________________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com">Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
<br></blockquote></div><br></div>