How Metro Works - Revision history

Drobbins: /* Introduction */

2012-09-13T03:36:21Z

‎Introduction

Ferdy: added link to download and other trivial changes

2011-02-19T21:06:38Z

added link to download and other trivial changes

Ferdy: /* Introduction */

2011-02-19T20:47:36Z

‎Introduction

Rh1: /* Adding a new sub architecture */

2011-02-06T15:13:48Z

‎Adding a new sub architecture

Drobbins at 21:31, 17 January 2011

2011-01-17T21:31:50Z

Kipibenkipod: /* Overview */ its subarch and not target/subarch

2011-01-14T17:52:11Z

‎Overview: its subarch and not target/subarch

404 Error: /* Have you ever noticed ? */

2011-01-10T12:23:36Z

‎Have you ever noticed ?

404 Error: /* How things works ? */

2011-01-09T22:59:32Z

‎How things works ?

404 Error: /* The GNU toolchain */

2011-01-09T18:50:35Z

‎The GNU toolchain

404 Error: /* Have you ever noticed ? */

2011-01-09T18:41:47Z

‎Have you ever noticed ?

@@ Line 4: / Line 4: @@
 Of course, [[Metro]] needs a seed to start its work and will recompile things like the so well known <tt>gcc</tt> and <tt>glibc</tt>.
 A 'seed' is either a pre-built stage3 archive available on any Funtoo Linux [http://docs.funtoo.org/wiki/Download mirror] or a snapshot of your current [[Funtoo Linux]] installation.
 = Arborescence description =

@@ Line 1: / Line 1: @@
 = Introduction =
-Metro is a somewhat complex set of shell scripts and various files that automagically creates stages 1/2/3 tarballs used to emerge your Funtoo system. Of course, Metro needs a seed to start its work and will recompile things like the so well known gcc and glibc. A 'seed' is either pre-built a stage 3 archive available on any Funtoo mirror or a snapshot of your current Funtoo installation . Hint : those who use BTRFS/ZFS or any snapshotable filesystem will enjoy their choice here :-)
+[[Metro]] is a somewhat complex set of shell (specifically bash) and python scripts and various files that automagically creates stages 1/2/3 tarballs used to emerge your [[Funtoo Linux]] system.
 = Arborescence description =

@@ Line 1: / Line 1: @@
 = Introduction =
-Metro is a somewhat complex set of shell scripts and various files that automagically creates stages 1/2/3 tarballs used to emerge your Funtoo system. Of course, Metro needs a seed to start its work and will recompile things like the so well known gcc and glibc. A 'seed' is either pre-built a stage 3 archive available on any Funtoo mirror or a snpashot of your current Funtoo installation . Hint : those who use BTRFS/ZFS or any snapshotable filesystem will enjoy their choice here :-)
+Metro is a somewhat complex set of shell scripts and various files that automagically creates stages 1/2/3 tarballs used to emerge your Funtoo system. Of course, Metro needs a seed to start its work and will recompile things like the so well known gcc and glibc. A 'seed' is either pre-built a stage 3 archive available on any Funtoo mirror or a snapshot of your current Funtoo installation . Hint : those who use BTRFS/ZFS or any snapshotable filesystem will enjoy their choice here :-)
 = Arborescence description =

@@ Line 213: / Line 213: @@
 = Adding a new sub architecture =
-As of January 2011, Metro can handle the IA-32 architecture (x86/32 and x/86 bits) as well as being able to handle several x86 flavous lying beneath the generic 'x86 and 'amd64' taxonomies. The example here is a try to add the necessary specification file to make it generate stage 1/2/3 tarballs for tiers architectures.
+As of January 2011, Metro can handle the IA-32 architecture (x86/32 and x86/64 bits) as well as being able to handle several x86 flavous lying beneath the generic 'x86 and 'amd64' taxonomies. The example here is a try to add the necessary specification file to make it generate stage 1/2/3 tarballs for tiers architectures.
 [[Category:Metro]]

← Older revision		Revision as of 21:31, 17 January 2011
Line 1:		Line 1:
		+	= Introduction =
		+
	Metro is a somewhat complex set of shell scripts and various files that automagically creates stages 1/2/3 tarballs used to emerge your Funtoo system. Of course, Metro needs a seed to start its work and will recompile things like the so well known gcc and glibc. A 'seed' is either pre-built a stage 3 archive available on any Funtoo mirror or a snpashot of your current Funtoo installation . Hint : those who use BTRFS/ZFS or any snapshotable filesystem will enjoy their choice here :-)		Metro is a somewhat complex set of shell scripts and various files that automagically creates stages 1/2/3 tarballs used to emerge your Funtoo system. Of course, Metro needs a seed to start its work and will recompile things like the so well known gcc and glibc. A 'seed' is either pre-built a stage 3 archive available on any Funtoo mirror or a snpashot of your current Funtoo installation . Hint : those who use BTRFS/ZFS or any snapshotable filesystem will enjoy their choice here :-)

@@ Line 153: / Line 153: @@
 # Python is the master of the house, everything (or at least near everything) in Funtoo tools is written Python, and as being a Funtoo tool, Metro in itself plus all of the stuff it uses are written in Python.
 # The first place to start with Metro tweaking are the .spec files located under '''targets/gentoo'''. Those files control what Metro does at each stage and are basically a melt of Metro directives and some Python embedded scripts and BASH embedded scripts. If something goes wrong.
-# Another good place to look at is '''targets/subarch''' : you will find here a couple of .spec files that governs how the build toolchain (libc, c/c++ compiler and related tools) will be generated, how they will be used (notice the CHOST variable) and at the end what will be put in the make.conf file in your stages archives.
+# Another good place to look at is '''subarch''' : you will find here a couple of .spec files that governs how the build toolchain (libc, c/c++ compiler and related tools) will be generated, how they will be used (notice the CHOST variable) and at the end what will be put in the make.conf file in your stages archives.
 The [[Metro Data Model]] page explains the logic used in spec files.

@@ Line 190: / Line 190: @@
 * '''libC''' : gnu (for glibc), ulibc...
-This is stricly conventional but powerful as it allows the toolchain to easily detect when you want to build it as a native toolchain or a cross-compilation toolchain. Also note that some architectures like SPARC version 9 (i.e. UltraSPARC) uses a 64 bits kernel and 32 bits userland binaries (although it is possible to have 64 bits binaries, most of the time producing 64 bits binaries does not bring any advantage and worse, can degrade the performance on some machines due to additional memory read/write cycles required to get/write 64 bits values). This is exactly the reason why you have '''sys-devel/gcc''' and '''sys-devel/kgcc64''', the later being only used to build the system kernel.
+This is stricly conventional but powerful as it allows the toolchain to easily detect when it has to be build it as a native toolchain or as a cross-compilation toolchain. Also note that some architectures like SPARC version 9 (i.e. UltraSPARC) uses a 64 bits kernel and 32 bits userland binaries (although it is possible to have 64 bits binaries, most of the time producing 64 bits binaries does not bring any advantage and worse, can degrade the performance on some machines due to additional memory read/write cycles required to get/write 64 bits values). This is exactly the reason why you have '''sys-devel/gcc''' and '''sys-devel/kgcc64''', the later being only used to build the system kernel.
 Now lets have a look on your machine at :

@@ Line 202: / Line 202: @@
 = How things works ? =
-TODO
 = Adding a new sub architecture =

← Older revision		Revision as of 18:50, 9 January 2011
Line 178:		Line 178:

	* '''a cross-compilation chain''' : the computer that runs the toolchain is NOT the same that executes the produced the toolchain (e.g. an i686 processor running GNU/Linux with the GNU Lib C produces a toolchain that generates binaries for a SPARC machine running Solaris). Moreover, you can do funny brain-dead things like : generate a toolchain running on a PowerPC GNU/Linux system that produces another toolchain targeting a SPARC machine under Solaris which, in its turn, produces binaries targeting an Alpha machine running under FreeBSD).		* '''a cross-compilation chain''' : the computer that runs the toolchain is NOT the same that executes the produced the toolchain (e.g. an i686 processor running GNU/Linux with the GNU Lib C produces a toolchain that generates binaries for a SPARC machine running Solaris). Moreover, you can do funny brain-dead things like : generate a toolchain running on a PowerPC GNU/Linux system that produces another toolchain targeting a SPARC machine under Solaris which, in its turn, produces binaries targeting an Alpha machine running under FreeBSD).
−
−	Playing with the cross-compilation capablities of the GNU toolchain is out the scope of this article, just retain on this subject that it is mainly used with embedded systems which have too few resources to host a full compilation system or in build farms that generates binaries for several CPU architectures.

	== Have you ever noticed ? ==		== Have you ever noticed ? ==