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 > <ajlen...@dynamicdevices.co.uk <mailto:ajlen...@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@lists.ximian.com > <mailto:Mono-devel-list@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.
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list