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" <ajlen...@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 <ajlen...@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 < >> 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 >>> 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@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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list