<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi,</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 22, 2014 at 9:53 PM, Miguel de Icaza <span dir="ltr"><<a href="mailto:miguel@xamarin.com" target="_blank">miguel@xamarin.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey guys,<div><br></div><div>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.</div>
<div>

<br></div><div>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.</div>


<div><br></div><div>To build a complete System.dll for a particular profile (net_2_0, net_4_0, etc) takes three steps: </div><div><ul><li>Core Build</li><li>Secondary Build:</li><ul><li>Core Build + </li><li>Defines: XML_DEP + SECURITY_DEP</li>


<li>Refs: </li><ul><li>-r:PrebuiltSystem=../lib/Previous/System.dll </li><li>-r:System.Xml.dll<br></li><li>-r:MonoSecurity=Mono.Security.dll</li></ul></ul><li>Final Build:</li><ul><li>Secondary Build + </li><li>defines: -d:CONFIGURATION_DEP</li>


<li>Refs:</li><ul><li>System.Configuration.dll</li></ul></ul></ul></div></div></blockquote><div><div class="gmail_default" style="font-size:small">Another option is to take advantage of the fact that ilasm does not require referenced assemblies to exist.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The idea would be do to the following:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">
Once:</div><div class="gmail_default" style="font-size:small">* Use any existing mscorlib.dll, System.dll and System.XML.dll to create <a href="http://mscorlib.il">mscorlib.il</a>, System.il and <a href="http://System.XML.il">System.XML.il</a> (possibly by using mono-cil-strip so that only the metadata remains). We commit these files to the repository.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">During the build:</div><div class="gmail_default" style="font-size:small">* Compile the *.il files to a set of reference assemblies (note that since ilasm does not require referenced assemblies to exist, we can compile <a href="http://mscorlib.il">mscorlib.il</a> to a mscorlib.dll that references System.dll before System.dll exists).</div>
<div class="gmail_default" style="font-size:small">* Use those reference assemblies to compile the final mscorlib.dll, System.dll and System.XML.dll</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">
Pros:</div><div class="gmail_default" style="font-size:small">* No circular build magic required.</div><div class="gmail_default" style="font-size:small">* The build should be faster, each assembly is compiled at most twice (once the .il and once the final assembly). With the current setup we compile some assemblies three times.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Cons:</div><div class="gmail_default" style="font-size:small">* It'll probably be painful to update/create new .il files when new profiles comes out from Microsoft.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Rolf</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div>The above is what is required to bring up System.</div></div><div><br></div><div>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.</div>


<div><br></div><div>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!)</div>


<div><br></div><div>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.</div><div><br></div><div>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.</div>


<div><br></div><div>These are the defines that we use to bring up System for each profile:</div><div><br></div><div>basic Profile:</div><div>







<p>basic: -d:NET_1_1 -d:NET_2_0 -d:BOOTSTRAP_BASIC -d:CONFIGURATION_2_0</p>
<p>basic: -d:NET_1_1 -d:NET_2_0 -d:BOOTSTRAP_BASIC -d:CONFIGURATION_2_0 -d:XML_DEP</p>
<p><br></p><p>Build Profile:</p>
<p>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</p><p>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</p>
<p><br></p><p>Net 2.0 profile:</p>
<p>net_2_0: -d:NET_1_1 -d:NET_2_0  -d:CONFIGURATION_2_0</p>
<p>net_2_0: -d:NET_1_1 -d:NET_2_0  -d:CONFIGURATION_2_0  -d:XML_DEP -d:SECURITY_DEP </p>
<p>net_2_0: -d:NET_1_1 -d:NET_2_0  -d:CONFIGURATION_2_0  -d:XML_DEP -d:SECURITY_DEP -d:CONFIGURATION_DEP </p>
<p><br></p><p>Net 4.0 profile:<br></p>
<p>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</p>
<p>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</p>
<p>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</p>
<p><br></p><p>Net 4.5 profile:<br></p>
<p>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 </p>
<p>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 </p>
<p>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 </p><span class="HOEnZb"><font color="#888888">
<p><br></p></font></span></div><span class="HOEnZb"><font color="#888888"><div>Miguel</div></font></span></div>
<br>_______________________________________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com">Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><span style="background-color:transparent;font-family:Arial;line-height:14.720000267028809px;vertical-align:baseline;white-space:pre-wrap">Explore <a href="http://xamarin.com/university" style="color:rgb(17,85,204);text-decoration:none;font-family:arial,sans-serif" target="_blank">Xamarin University</a></span><span style="background-color:transparent;line-height:14.720000267028809px;vertical-align:baseline;white-space:pre-wrap;font-family:Arial">—unlimited, live, online, mobile training around the clock.  </span><br>
</div>
</div></div>