[Mono-dev] Repeat builds of core assemblies
Miguel de Icaza
miguel at xamarin.com
Thu May 15 04:03:37 UTC 2014
Hello!
Final update!
I got all the code working with the new dependencies!
The code lives in the "staged-cyclic-builds" branch, and I believe it is
ready to merge. Will do one final human inspection before I do so.
Miguel
On Tue, May 13, 2014 at 11:37 PM, Miguel de Icaza <miguel at xamarin.com>wrote:
> Hello Bryan,
>
> This is a step in the direction of having everything building with msbuild.
>
> Whether I will succeed or not, is yet to be determined :-)
>
> Miguel
>
>
> On Mon, May 12, 2014 at 12:07 PM, Bryan Crotaz <
> bryan.crotaz at silvercurve.co.uk> wrote:
>
>> Will this make building on windows possible?
>>
>> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20140515/2fc420f5/attachment-0001.html>
More information about the Mono-devel-list
mailing list