[Mono-dev] Building mono on Windows issues.

Fri Oct 17 07:09:40 UTC 2014

Hey Alex

There's a lot that you can do through their yml settings file. Download and
setup pretty much anything. Have a look in the root if the repo:
appveyor.yml.
On 17 Oct 2014 8:59 AM, "Alex J Lennon" <ajlennon at dynamicdevices.co.uk>
wrote:

>  Hi Mladen,
>
> Sounds good to me. I've not encountered Appveyor before but it looks good.
> How do you get the Cygwin dependencies in there? Can it be assumed that
> what's happening in the Appveyor build is basically the same as on a
> standard Windows box?
>
> Cheers,
>
> Alex
>
> On 17/10/2014 08:53, Mladen Mihajlovic wrote:
>
> 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.
>
>  Cheers,
> Mladen
>
> On 17 October 2014 08:46, Alex J Lennon <ajlennon at dynamicdevices.co.uk>
> wrote:
>
>>  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 <%2B44%20%280%297956%20668178> landline: +44
>> (0)1513 241374 <%2B44%20%280%291513%20241374>
>>
>>  [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
>>
>>
>
> --
>
> [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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20141017/9e774d49/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 800 bytes
Desc: not available
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20141017/9e774d49/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 3997 bytes
Desc: not available
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20141017/9e774d49/attachment-0007.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/9e774d49/attachment-0008.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/9e774d49/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 631 bytes
Desc: not available
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20141017/9e774d49/attachment-0010.png>
-------------- 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/9e774d49/attachment-0011.png>