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.cro...@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 <mig...@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 <mig...@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 <mig...@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@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list