[Mono-dev] Repeat builds of core assemblies

Rodrigo B. de Oliveira rodrigobamboo at gmail.com
Fri May 2 20:31:05 UTC 2014


kudos to you, Miguel!

On Fri, May 2, 2014 at 5: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
>


More information about the Mono-devel-list mailing list