[Mono-dev] Building mono on Windows issues.
Alex J Lennon
ajlennon at dynamicdevices.co.uk
Fri Oct 17 06:59:46 UTC 2014
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
> <mailto: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
>> <mailto: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
>> <mailto:Mono-devel-list at lists.ximian.com>
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>>
>
> --
>
> Dynamic Devices Ltd <http://www.dynamicdevices.co.uk/>
>
> Alex J Lennon / Director
> 1 Queensway, Liverpool L22 4RA
>
> mobile: +44 (0)7956 668178 <tel:%2B44%20%280%297956%20668178>
> landline: +44 (0)1513 241374 <tel:%2B44%20%280%291513%20241374>
>
> Linkedin <http://www.linkedin.com/in/alexjlennon> 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
> <mailto:Mono-devel-list at lists.ximian.com>
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
--
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
Linkedin <http://www.linkedin.com/in/alexjlennon> Skype
<skype:alexjlennon?add>
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/09d0ba7d/attachment-0001.html>
-------------- 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/09d0ba7d/attachment-0006.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/09d0ba7d/attachment-0007.png>
-------------- 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/09d0ba7d/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/09d0ba7d/attachment-0009.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/09d0ba7d/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/09d0ba7d/attachment-0011.png>
More information about the Mono-devel-list
mailing list