mono 1.2.5.1: added mono.bbclass, many changes required for packaging

New file: packages/mono/mono-mcs-intermediate_1.2.5.1.bb
Compiles mono in native mode with standard prefix, then tars up the
resulting tree and puts the tarfile into staging
New file: packages/mono/mono_files.py
Automatically generated using collect-path.py (attached to this mail)
and contains a list that maps file patterns to package names (and
contained assemblies, see below).
New file: classes/mono.bbclass
Has a helper function for the list that maps file patterns to package
names and assemblies (see below). Also has a function mono_do_clilibs
and inserts that function into PACKAGEFUNCS. This function calls
mono_find_provides_and_requires which finds out (through calls to
monodis --assembly and monodis --assemblyref) which assemblies are
provided and required by a particular package. mono_do_clilibs then
puts the information about provided assemblies into
${STAGING_DIR}/clilibs/${packagename}.list and information about the
required packages into ${PKGDEST}/{packagename}.clilibdeps where it
will later be picked up by the modified read_shlibdeps.
Originally I had dependency resolution through the partial list in
mono_files.py but obviously this doens't scale, so I implemented the
new method with mono_do_clilibs. The benefit is now that I don't really
need the extra information in mono_files.py anymore and can in
principle get rid of mono_get_file_table and related code. Instead it
should be possible to modify collect-paths.py to output bitbake .inc
code (e.g. PACKAGES = "..." and a whole lot of FILES_... = "...")
instead of python code. There's still the minor problem of how to
handle the .mdb files, that's why I didn't implement it yet but instead
opted for an approach that I knew would work. (Debian just puts
the .mdb files into the individual packages, while I would argue that
they do belong into corresponding -dbg packages.)
Modified file: classes/package.bbclass
In read_shlibdeps I folded the two identical code blocks dealing with
*.shlibdeps and *.pcdeps into one and added *.clilibdeps (generated by
mono_do_clilibs above).
Modified file: packages/mono/mono_1.2.5.1.bb
Add the mono-mcs-intermediate workaround. Add a whole lot of python
code in populate_packages_prepend in order to split up the packages
based on information from mono_files.py (via mono.bbclass'
mono_get_file_table). As I said above a lot of this code can hopefully
be replaced in the future.

1 files changed, 36 insertions, 7 deletions

diff --git a/packages/mono/README b/packages/mono/README
index 39479308b2..c3043faee3 100644
--- a/packages/mono/README
+++ b/packages/mono/README
@@ -1,10 +1,39 @@
-Mono in OE is still very much a work in progress.
-1.2.4 
-  - is reported to work on MIPS.  
-  - has floating point problems on ARM
+Notes on Mono support in OE.
+
+===============================
+Cross Compiling Mono
+
+Cross compiling mono requires a two stage build because the mono mcs directory
+cannot be built while cross compiling (http://www.mono-project.com/Mono:ARM).
+The recommended way to cross compile mono is to 
+
+ 1. do a complete build on the host system, and install.  
+ 2. cross compile mono which will only build the native target code and 
+    overlay the target binaries on the host install.  
+
+The MCS build (step 1) is implemented by the mono-mcs-intermediate* recipe.
+This recipe is very similiar to the native build, except it uses standard
+install prefixes and the install directory is tar'd up, and placed in staging
+for use by the cross build.
+
+During the mono cross build, the first step during the install is to untar
+the install results of the mcs-intermediate build.  The cross build install
+then proceeds to overlay the native binaries in the install directory.
+
+================================
+mono.bbclass
+
+Has a helper function for the list that maps file patterns to package
+names and assemblies (see below). Also has a function mono_do_clilibs
+and inserts that function into PACKAGEFUNCS. This function calls
+mono_find_provides_and_requires which finds out (through calls to
+monodis --assembly and monodis --assemblyref) which assemblies are
+provided and required by a particular package. mono_do_clilibs then
+puts the information about provided assemblies into
+${STAGING_DIR}/clilibs/${packagename}.list and information about the
+required packages into ${PKGDEST}/{packagename}.clilibdeps where it
+will later be picked up by the modified read_shlibdeps.
+
 
-1.2.5
-  - tested on ARM EABI.  Floating point issues have been worked around.
 
-There is still a lot of packaging work that needs done to package the mono dll's for installation.