[Mono-dev] Building mono on Windows issues.

Mladen Mihajlovic mmihajlovic at gmail.com
Fri Oct 17 06:53:16 UTC 2014

Hi Guys,

I took it upon myself to try and get a build up and running on Appveyor
yesterday. Please have a look at https://github.com/mika76/mono and
https://ci.appveyor.com/project/mmihajlovic/mono - so far the only thing
I've edited is the appveyor.yml file and the actual a[[veyor settings.

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.

If the msbuild does not pan out, the cygwin build can always be attempted
as well.

If anybody wants to help, let me know and I'll make you a contributor on
the repository.


On 17 October 2014 08:46, Alex J Lennon <ajlennon at dynamicdevices.co.uk>

>  Hi Jonathan,
> Thanks for taking the time to provide the background.
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
> >- 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
> 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.
> 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.
> 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.
> 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.
> If this was to be in place do you think there would be any other toolchain
> issues that would need consideration?
> >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.
> 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.
> 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
> 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
> people could then use in the absence of an official installer.
> > given the size and complexity of the mono build and tests, it was
> generally not robust. Especially for continuous and automated usage
> 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.
> >- it was slow. Slow as in hours on Windows vs minutes on Linux
> Yes, my guess is that it's perhaps related to forking on Windows under
> Cygwin but who knows.
> 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.
>  To me a first pass at needed actions are:
> - define one or more supported Windows build host platforms.
> - take the latest Mono 3.10.0 release and create an installer script for
> versioned build dependencies
> - create a simple build script and test script
> - understand how the packaging step works and automate this
> - 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)
> - fix issues with needing to change Cygwin headers for the compile to work.
> - setup a CI system building and reporting for master.
> 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.
> Cheers,
> Alex
> On 17/10/2014 03:21, Jonathan Chambers wrote:
> Hello,
>  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:
>  Release/Install/CI for Windows
>  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.
> As for cygwin, the main issues were:
> - 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
> - given the size and complexity of the mono build and tests, it was
> generally not robust. Especially for continuous and automated usage
> - it was slow. Slow as in hours on Windows vs minutes on Linux
>  Developing on Windows
>  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.
>  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.
>  - Jonathan
> On Thu, Oct 16, 2014 at 2:16 PM, Alex J Lennon <
> ajlennon at dynamicdevices.co.uk> wrote:
>> On 16/10/2014 16:58, Bryan Crotaz wrote:
>> > What's the estimation of effort required to get mono buildable in
>> > windows and debuggable in VS? 6 man months? 18 man months?
>> >
>> > I don't have time to donate but I'd be happy to put some money in a
>> > pot with some of you to hire someone to work on this full time. Feels
>> > like a concerted full time effort would bear more fruit than
>> > occasional toe-dips in the water.
>> Bryan,
>> fwiw - and this is merely a view from a bystander - I don't think it
>> would take a lot to address the Windows build itself today.
>> Mono does build on Windows, but it doesn't "just work" as people tend to
>> expect nowadays. It needs some stream-lining imho with some setup script
>> automation or similar for newbies. There are also some missing links in
>> how an official Windows release is created versus using make, as we end
>> up with missing files on install (or I am misunderstanding  something
>> that needs doing, which in itself would be a documentation issue).
>> To me this isn't a code issue so much as an ownership and release
>> management issue. I recognise there is a cost to that and there has to
>> be an ROI for that cost to be worth bearing.
>> Releases are made with broken Window builds as Vincent says. So imho
>> it's a dead work "fixing" master at any given time as it will just
>> become broken again, although some basic setup scripting to pull down
>> Cygwin, dependencies, to get the installation step working and such
>> would help people to get going, I feel.
>> What's more relevant, I believe, is a maintainer who has committed to
>> Windows build testing and patching prior to an  offical release of Mono,
>> a buy-in from other release maintainers that this is worth doing (or
>> what's the point?), and perhaps some CI running the Mono tests in the
>> background.
>> Just my 4 cents,
>> Alex
>>  _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> --
> [image: Dynamic Devices Ltd] <http://www.dynamicdevices.co.uk/>
> Alex J Lennon / Director
> 1 Queensway, Liverpool L22 4RA
> mobile: +44 (0)7956 668178 landline: +44 (0)1513 241374
>  [image: Linkedin] <http://www.linkedin.com/in/alexjlennon> [image: Skype]
> 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.
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20141017/1b8457f1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: skype.png
Type: image/png
Size: 800 bytes
Desc: not available
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20141017/1b8457f1/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linkedin.png
Type: image/png
Size: 631 bytes
Desc: not available
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20141017/1b8457f1/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ddlogo-4.png
Type: image/png
Size: 3997 bytes
Desc: not available
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20141017/1b8457f1/attachment-0005.png>

More information about the Mono-devel-list mailing list