1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/docs/1 - Introduction.txt Sat Aug 14 16:37:11 2010 +0200
1.3 @@ -0,0 +1,108 @@
1.4 +File.........: 1 - Introduction.txt
1.5 +Copyrigth....: (C) 2010 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
1.6 +License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5
1.7 +
1.8 +
1.9 +Introduction /
1.10 +_____________/
1.11 +
1.12 +
1.13 +crosstool-NG aims at building toolchains. Toolchains are an essential component
1.14 +in a software development project. It will compile, assemble and link the code
1.15 +that is being developed. Some pieces of the toolchain will eventually end up
1.16 +in the resulting binary/ies: static libraries are but an example.
1.17 +
1.18 +So, a toolchain is a very sensitive piece of software, as any bug in one of the
1.19 +components, or a poorly configured component, can lead to execution problems,
1.20 +ranging from poor performance, to applications ending unexpectedly, to
1.21 +mis-behaving software (which more than often is hard to detect), to hardware
1.22 +damage, or even to human risks (which is more than regrettable).
1.23 +
1.24 +Toolchains are made of different piece of software, each being quite complex
1.25 +and requiring specially crafted options to build and work seamlessly. This
1.26 +is usually not that easy, even in the not-so-trivial case of native toolchains.
1.27 +The work reaches a higher degree of complexity when it comes to cross-
1.28 +compilation, where it can become quite a nightmare...
1.29 +
1.30 +Some cross-toolchains exist on the internet, and can be used for general
1.31 +development, but they have a number of limitations:
1.32 + - they can be general purpose, in that they are configured for the majority:
1.33 + no optimisation for your specific target,
1.34 + - they can be prepared for a specific target and thus are not easy to use,
1.35 + nor optimised for, or even supporting your target,
1.36 + - they often are using aging components (compiler, C library, etc...) not
1.37 + supporting special features of your shiny new processor;
1.38 +On the other side, these toolchain offer some advantages:
1.39 + - they are ready to use and quite easy to install and setup,
1.40 + - they are proven if used by a wide community.
1.41 +
1.42 +But once you want to get all the juice out of your specific hardware, you will
1.43 +want to build your own toolchain. This is where crosstool-NG comes into play.
1.44 +
1.45 +There are also a number of tools that build toolchains for specific needs,
1.46 +which are not really scalable. Examples are:
1.47 + - buildroot (buildroot.uclibc.org) whose main purpose is to build root file
1.48 + systems, hence the name. But once you have your toolchain with buildroot,
1.49 + part of it is installed in the root-to-be, so if you want to build a whole
1.50 + new root, you either have to save the existing one as a template and
1.51 + restore it later, or restart again from scratch. This is not convenient,
1.52 + - ptxdist (www.pengutronix.de/software/ptxdist), whose purpose is very
1.53 + similar to buildroot,
1.54 + - other projects (openembedded.org for example), which are again used to
1.55 + build root file systems.
1.56 +
1.57 +crosstool-NG is really targeted at building toolchains, and only toolchains.
1.58 +It is then up to you to use it the way you want.
1.59 +
1.60 +
1.61 +History |
1.62 +--------+
1.63 +
1.64 +crosstool was first 'conceived' by Dan Kegel, who offered it to the community
1.65 +as a set of scripts, a repository of patches, and some pre-configured, general
1.66 +purpose setup files to be used to configure crosstool. This is available at
1.67 +http://www.kegel.com/crosstool, and the subversion repository is hosted on
1.68 +google at http://code.google.com/p/crosstool/.
1.69 +
1.70 +I once managed to add support for uClibc-based toolchains, but it did not make
1.71 +into mainline, mostly because I didn't have time to port the patch forward to
1.72 +the new versions, due in part to the big effort it was taking.
1.73 +
1.74 +So I decided to clean up crosstool in the state it was, re-order the things
1.75 +in place, add appropriate support for what I needed, that is uClibc support
1.76 +and a menu-driven configuration, named the new implementation crosstool-NG,
1.77 +(standing for crosstool Next Generation, as many other comunity projects do,
1.78 +and as a wink at the TV series "Star Trek: The Next Generation" ;-) ) and
1.79 +made it available to the community, in case it was of interest to any one.
1.80 +
1.81 +
1.82 +Referring to crosstool-NG |
1.83 +--------------------------+
1.84 +
1.85 +The long name of the project is crosstool-NG:
1.86 + * no leading uppercase (except as first word in a sentence)
1.87 + * crosstool and NG separated with a hyphen (dash)
1.88 + * NG in uppercase
1.89 +
1.90 +Crosstool-NG can also be referred to by its short name CT-NG:
1.91 + * all in uppercase
1.92 + * CT and NG separated with a hyphen (dash)
1.93 +
1.94 +The long name is preferred over the short name, except in mail subjects, where
1.95 +the short name is a better fit.
1.96 +
1.97 +When referring to a specific version of crosstool-NG, append the version number
1.98 +either as:
1.99 + * crosstool-NG X.Y.Z
1.100 + - the long name, a space, and the version string
1.101 + * crosstool-ng-X.Y.Z
1.102 + - the long name in lowercase, a hyphen (dash), and the version string
1.103 + - this is used to name the release tarballs
1.104 + * crosstool-ng-X.Y.Z+hg_id
1.105 + - the long name in lowercase, a hyphen, the version string, and the Hg id
1.106 + (as returned by: ct-ng version)
1.107 + - this is used to differentiate between releases and snapshots
1.108 +
1.109 +The frontend to crosstool-NG is the command ct-ng:
1.110 + * all in lowercase
1.111 + * ct and ng separated by a hyphen (dash)