scripts/functions: svn retrieval first tries the mirror for tarballs
The svn download helper looks for the local tarballs dir to see if it
can find a pre-downloaded tarball, and if it does not find it, does
the actual fetch to upstream via svn.
In the process, it does not even try to get a tarball from the local
mirror, which can be useful if the mirror has been pre-populated
manually (or with a previously downloaded tree).
Fake a tarball get with the standard tarball-download helper, but
without specifying any upstream URL, which makes the helper directly
try the LAN mirror.
Of course, if no mirror is specified, no URL wil be available, and
the standard svn retrieval will kick in.
Reported-by: ANDY KENNEDY <ANDY.KENNEDY@adtran.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
1 File.........: 6 - Toolchain types.txt
2 Copyright....: (C) 2010 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
3 License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5
10 There are four kinds of toolchains you could encounter.
12 First off, you must understand the following: when it comes to compilers there
13 are up to four machines involved:
14 1) the machine configuring the toolchain components: the config machine
15 2) the machine building the toolchain components: the build machine
16 3) the machine running the toolchain: the host machine
17 4) the machine the toolchain is generating code for: the target machine
19 We can most of the time assume that the config machine and the build machine
20 are the same. Most of the time, this will be true. The only time it isn't
21 is if you're using distributed compilation (such as distcc). Let's forget
22 this for the sake of simplicity.
24 So we're left with three machines:
29 Any toolchain will involve those three machines. You can be as pretty sure of
30 this as "2 and 2 are 4". Here is how they come into play:
32 1) build == host == target
33 This is a plain native toolchain, targeting the exact same machine as the
34 one it is built on, and running again on this exact same machine. You have
35 to build such a toolchain when you want to use an updated component, such
36 as a newer gcc for example.
37 crosstool-NG calls it "native".
39 2) build == host != target
40 This is a classic cross-toolchain, which is expected to be run on the same
41 machine it is compiled on, and generate code to run on a second machine,
43 crosstool-NG calls it "cross".
45 3) build != host == target
46 Such a toolchain is also a native toolchain, as it targets the same machine
47 as it runs on. But it is build on another machine. You want such a
48 toolchain when porting to a new architecture, or if the build machine is
49 much faster than the host machine.
50 crosstool-NG calls it "cross-native".
52 4) build != host != target
53 This one is called a canadian-toolchain (*), and is tricky. The three
54 machines in play are different. You might want such a toolchain if you
55 have a fast build machine, but the users will use it on another machine,
56 and will produce code to run on a third machine.
57 crosstool-NG calls it "canadian".
59 crosstool-NG can build all these kinds of toolchains (or is aiming at it,
62 (*) The term Canadian Cross came about because at the time that these issues
63 were all being hashed out, Canada had three national political parties.
64 http://en.wikipedia.org/wiki/Cross_compiler