[Mono-dev] Repeat builds of core assemblies

Bryan Crotaz bryan.crotaz at silvercurve.co.uk
Mon May 12 16:37:10 UTC 2014


I'd like to get to a point where a newbie can install cygwin, check out
from git, and make.  C'est tout.


On 12 May 2014 17:35, Alex J Lennon <ajlennon at dynamicdevices.co.uk> wrote:

>
> On 12/05/2014 17:30, Bryan Crotaz 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.
>
>
> That's an interesting idea Bryan. I'd love it if the Win32 build process
> was a little more streamlined but I wouldn't know where to begin myself
> within the Mono build scripting at present.
>
> In the short-term it might be possible to do something with a script using
> one of the command-line package managers for Cygwin (e.g. apt-cyg)
>
> I could have a look at that when I have time maybe if the Cygwin UI setup
> app is proving a hurdle.
>
>
>
> 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
>
>
> --
>
> [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/04c2f0da/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/20140512/04c2f0da/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/04c2f0da/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/20140512/04c2f0da/attachment-0005.png>


More information about the Mono-devel-list mailing list