[Mono-dev] Repeat builds of core assemblies
Bryan Crotaz
bryan.crotaz at silvercurve.co.uk
Mon May 12 17:20:30 UTC 2014
We've been persuading C# shops to use the Raspberry Pi platform and build
scripts aren't that much of an issue for them regarding acceptance. Being
able to fix bugs quickly and easily without having to fight the build
system is more important to getting lots of contributors.
If we could have an automated build that:
1. builds
2. tests
3. creates Windows installer
4. deploys the installer to a VM and tries some smoke tests
5. creates linux packages
6. deploys the package to a VM and tries some smoke tests
7. publishes artifacts to wiki, and to public repos (e.g. Debian package
repo)
and stops at first failure, emailing the results to the list...
Then we'd have a system that could be hooked up to test pull requests
automatically and reject any that fail, and we've have immediate
availability of all build versions to newbies.
The first step is a clean build script that JustWorks (TM). Sounds like
you're nearly there.
On 12 May 2014 17:49, Alex J Lennon <ajlennon at dynamicdevices.co.uk> wrote:
>
> On 12/05/2014 17:35, Bryan Crotaz wrote:
>
> There's a lot of references in your document to build failures and
> potential future build failures.
>
> Can I suggest that pull-requests are only accepted if they don't break
> the build? It's surely the developer's responsibility to make sure that
> they haven't created any conflicts, or have correctly documented extra
> cygwin packages that are needed, or have correctly edited the Windows
> installer to include all the correct files.
>
> This way, newbie contributors can be guaranteed that they can download
> the latest default branch from git and can build it. Then they can get on
> with being productive instead of being put off by a whole load of errors
> they won't understand.
>
>
> I'm just somebody who believes in Mono and would like to help faciliate
> others to be able to use it as I do.
>
> I do hope the folks behind Mono come back to your on your suggestion
> though, as I too believe that with a little
> effort each release tarball could be QA'd to be sure it builds without
> error on each target platform.
>
> I believe time spent that way would go a long way to drive acceptance of
> Mono as a viable alternative for businesses.
>
> Cheers, Alex
>
>
> Bryan
>
>
> On 12 May 2014 17:30, Bryan Crotaz <bryan.crotaz at silvercurve.co.uk> wrote:
>
>> Ooooh pretty..... Will give it a go.
>>
>> Can the build script be extended to install needed cygwin packages if
>> they're missing? When I first tried to build I had no idea how to find the
>> packages, or how to install them - for newbie contributors this would
>> remove a lot (in my case 2 days) of head scratching.
>>
>>
>> On 12 May 2014 17:23, Alex J Lennon <ajlennon at dynamicdevices.co.uk>wrote:
>>
>>>
>>> On 12/05/2014 17:07, Bryan Crotaz wrote:
>>>
>>> Will this make building on windows possible?
>>>
>>> Bryan,
>>>
>>> I've written a walkthrough here for building 3.4.0 from the release
>>> tarball and 3.4.1 from git on Windows.
>>>
>>> http://www.codeproject.com/Articles/769292/How-to-build-Mono-on-Windows
>>>
>>> Best regards, Alex
>>>
>>>
>>> Bryan Crotaz
>>> Silver Curve
>>>
>>> On 12 May 2014, at 16:59, Miguel de Icaza <miguel at xamarin.com> wrote:
>>>
>>> Hey guys,
>>>
>>> Another update: I am almost done with the work, only one cycle left to
>>> resolve and I will be able to land the changes.
>>>
>>> All the changes are on a branch on github.
>>>
>>> MIguel
>>>
>>>
>>> On Fri, May 2, 2014 at 4:27 PM, Miguel de Icaza <miguel at xamarin.com>wrote:
>>>
>>>> Hello guys,
>>>>
>>>> Just a follow up to my previous posting on this.
>>>>
>>>> I have managed to untangle this mess, and now I have a clean build
>>>> that does not involve overwriting assemblies.
>>>>
>>>> In addition to untangling this, I added dependencies on all the
>>>> assemblies involved in this circular dependency mess so if you type "make"
>>>> in any of System, System.Xml, System.Security, Mono.Security or
>>>> System.Configuration, all the dependencies will be properly built.
>>>>
>>>> During the fixing, I noticed that our System.Xml build must have
>>>> broke a few eons ago, because there was code in place to perform a 2-stage
>>>> System.Xml build as well (without and with System.Configuration support),
>>>> but nobody noticed that this had happened. While I fixed this, it raises
>>>> the obvious point that nobody really cares (or likes) System.Configuration.
>>>>
>>>> While doing this review, I found a few other places that also have
>>>> these ugly loops, so I am going to be fixing those as well.
>>>>
>>>> Miguel
>>>>
>>>>
>>>> On Tue, Apr 22, 2014 at 3:53 PM, Miguel de Icaza <miguel at xamarin.com>wrote:
>>>>
>>>>> Hey guys,
>>>>>
>>>>> I was looking at making the MSBuild system work, and during the
>>>>> process I have encountered a few problems that we have in our existing
>>>>> build system that are problematic.
>>>>>
>>>>> The problem is that System, System.XML and System.Configuration are
>>>>> each defined in terms of the other assemblies. So we gradually bring up
>>>>> each one of those assemblies up by first compiling a stub System, which we
>>>>> use to build System.XML and System.Configuration. Then we rebuild System,
>>>>> this time referencing System.XML and System.Configuration so we can take a
>>>>> dependency on them, and so on.
>>>>>
>>>>> To build a complete System.dll for a particular profile (net_2_0,
>>>>> net_4_0, etc) takes three steps:
>>>>>
>>>>> - Core Build
>>>>> - Secondary Build:
>>>>> - Core Build +
>>>>> - Defines: XML_DEP + SECURITY_DEP
>>>>> - Refs:
>>>>> - -r:PrebuiltSystem=../lib/Previous/System.dll
>>>>> - -r:System.Xml.dll
>>>>> - -r:MonoSecurity=Mono.Security.dll
>>>>> - Final Build:
>>>>> - Secondary Build +
>>>>> - defines: -d:CONFIGURATION_DEP
>>>>> - Refs:
>>>>> - System.Configuration.dll
>>>>>
>>>>> The above is what is required to bring up System.
>>>>>
>>>>> Our implementation has one major problem: it overwrites the
>>>>> intermediate files. So the core build output is overwritten by the
>>>>> secondary build, and the secondary build is overwritten by the final build.
>>>>>
>>>>> It seems that historically, instead of introducing temporary
>>>>> directories for each stage, instead we hacked our way out of it. We
>>>>> introduced a LIBRARY_USE_INTERMEDIATE_FILE whose sole purpose was to work
>>>>> around the case where Windows was actively telling us we were doing
>>>>> something wrong (we were overwriting a file that we were actively
>>>>> referencing!)
>>>>>
>>>>> The above is also likely going to prevent reliable parallel builds,
>>>>> or probably means that we introduced some gross hack to make the above work
>>>>> in parallel.
>>>>>
>>>>> I am going to try to fix this, but the Makefile goop is pretty
>>>>> dense, and I might fail. I just figured I should share my findings in
>>>>> case civilization comes to an end and a future archeologist tries to figure
>>>>> out why this was not working.
>>>>>
>>>>> These are the defines that we use to bring up System for each
>>>>> profile:
>>>>>
>>>>> basic Profile:
>>>>>
>>>>> basic: -d:NET_1_1 -d:NET_2_0 -d:BOOTSTRAP_BASIC -d:CONFIGURATION_2_0
>>>>>
>>>>> basic: -d:NET_1_1 -d:NET_2_0 -d:BOOTSTRAP_BASIC -d:CONFIGURATION_2_0
>>>>> -d:XML_DEP
>>>>>
>>>>>
>>>>> Build Profile:
>>>>>
>>>>> build: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0
>>>>> -d:CONFIGURATION_2_0
>>>>>
>>>>> build: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0
>>>>> -d:CONFIGURATION_2_0 -d:XML_DEP
>>>>>
>>>>>
>>>>> Net 2.0 profile:
>>>>>
>>>>> net_2_0: -d:NET_1_1 -d:NET_2_0 -d:CONFIGURATION_2_0
>>>>>
>>>>> net_2_0: -d:NET_1_1 -d:NET_2_0 -d:CONFIGURATION_2_0 -d:XML_DEP
>>>>> -d:SECURITY_DEP
>>>>>
>>>>> net_2_0: -d:NET_1_1 -d:NET_2_0 -d:CONFIGURATION_2_0 -d:XML_DEP
>>>>> -d:SECURITY_DEP -d:CONFIGURATION_DEP
>>>>>
>>>>>
>>>>> Net 4.0 profile:
>>>>>
>>>>> net_4_0: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0
>>>>> -d:CONFIGURATION_2_0
>>>>>
>>>>> net_4_0: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0
>>>>> -d:CONFIGURATION_2_0 -d:XML_DEP -d:SECURITY_DEP
>>>>>
>>>>> net_4_0: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0
>>>>> -d:CONFIGURATION_2_0 -d:XML_DEP -d:SECURITY_DEP -d:CONFIGURATION_DEP
>>>>>
>>>>>
>>>>> Net 4.5 profile:
>>>>>
>>>>> net_4_5: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0
>>>>> -d:NET_4_5 -d:CONFIGURATION_2_0
>>>>>
>>>>> net_4_5: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0
>>>>> -d:NET_4_5 -d:CONFIGURATION_2_0 -d:XML_DEP -d:SECURITY_DEP
>>>>>
>>>>> net_4_5: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0
>>>>> -d:NET_4_5 -d:CONFIGURATION_2_0 -d:XML_DEP -d:SECURITY_DEP
>>>>> -d:CONFIGURATION_DEP
>>>>>
>>>>>
>>>>> Miguel
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>>
>>>
>>> _______________________________________________
>>> Mono-devel-list mailing listMono-devel-list at lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>>
>>>
>>
>>
>> --
>> Bryan Crotaz
>> Managing Director
>> Silver Curve
>>
>
>
>
> --
> Bryan Crotaz
> Managing Director
> Silver Curve
>
>
> --
>
> [image: Dynamic Devices Ltd] <http://www.dynamicdevices.co.uk/>
>
> Alex J Lennon / Director
> 1 Queensway, Liverpool L22 4RA
>
> mobile: +44 (0)7956 668178
>
> [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.
>
--
Bryan Crotaz
Managing Director
Silver Curve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20140512/0ee2bc37/attachment-0001.html>
-------------- 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/20140512/0ee2bc37/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/20140512/0ee2bc37/attachment-0004.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/20140512/0ee2bc37/attachment-0005.png>
More information about the Mono-devel-list
mailing list