[Mono-dev] Building mono on Windows issues.
Alex J Lennon
ajlennon at dynamicdevices.co.uk
Fri Oct 17 06:46:51 UTC 2014
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 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/552e9419/attachment-0001.html>
-------------- 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/552e9419/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/552e9419/attachment-0004.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/552e9419/attachment-0005.png>
More information about the Mono-devel-list
mailing list