From: Miguel de Icaza <miguel@gnome.org>
Date: Fri, 16 May 2014 19:48:41 +0000 (-0400)
Subject: Merge pull request #1041 from mono/staged-cyclic-builds
X-Git-Url: http://wien.tomnetworks.com/gitweb/?a=commitdiff_plain;h=a3de5976ed5e64512bfb821e053370b2df2028ff;p=mono.git

Merge pull request #1041 from mono/staged-cyclic-builds

This patch introduces an infrastructure to stage the builds for the core
assemblies that have cyclic dependencies.   This deals directly with
the following cycle:

    System.dll requires:
	System.Configuration.dll
	Mono.Security.dll
	System.Xml.dll

	They all require System.dll to be built

    System.Xml requires:
	System.dll
	System.Configuration.dll

    System.Security.dll requires:
	System.dll
	Mono.Security.dll
	System.Xml.dll

Principle
=========

The patch works by directing the build infrastructure to place
intermediate build steps on their own directory.  For example the
first System.dll build that only takes a dependency in mscorlib.dll is
placed not under the final directory but on a subdirectory called
"bare".

The second time that System.dll is built (after Mono.Security and
System.Xml have been built) is placed on the "secxml" directory.

The third time is the final build, and that one ends in the profile
directory.

The same principle is applied to System.Xml.

Better Dependency Tracking
==========================

To handle the multiple stages, the new Makefiles for the various
parties involved in this loop are now able to build their
dependencies.  This means that typing "make" on System.Security or
System.Xml or System will build all of the intermediate steps as
required, without needing the toplevel Makefile to perform multiple
build shots to incrementally build the result.

Bug fixes
=========

We must have regressed at some point the build of System.Xml as we
were only doing one build of it, one without System.Configuration
support.  This patch introduces back the changes to build System.Xml
in two steps.

This patch fixes the setup where we end up rebuilding System.dll and
overwriting it two times as the build progresses as a side effect
(this is what required LIBRARY_USE_INTERMEDIATE_FILE).

Details
=======

library.make:

	Introduces a new "the_libdir_base" which is the raw directory
	where the final output will go.   This points to the same location
	that libdir_base previously pointed to.

	The existing libdir_base is modified to contain an optional
	"intermediate" directory, where intermediate builds can be
	placed.
---

a3de5976ed5e64512bfb821e053370b2df2028ff