diff options
author | Rob Savoye <rob.savoye@linaro.org> | 2016-06-23 12:30:46 -0600 |
---|---|---|
committer | Rob Savoye <rob.savoye@linaro.org> | 2016-06-23 12:30:46 -0600 |
commit | 679a5ff13d7336dbe7a4adaa1dd48be97ed1d79c (patch) | |
tree | 0682b9ceffb71df13c9a183d1952e7b2449eca84 /README | |
parent | 7597d5cebee12824de773945fa0061fb37a94c42 (diff) |
Diffstat (limited to 'README')
-rw-r--r-- | README | 282 |
1 files changed, 1 insertions, 281 deletions
@@ -1,281 +1 @@ - README - -Cbuildv2 is a bourne shell rewrite of the existing cbuild system as -used by Linaro. While being oriented to the Linaro way of doing -things, Cbuildv2 should be usable by others by just reconfiguring. - -Configuring Cbuildv2: ---------------------- - While it is possible to run Cbuildv2 from it's source tree, this -isn't recommended. The best practice is to create a new build -directory, and configure Cbuildv2 in that directory. That makes it -easy to change branches, or even delete subdirectories. There -are defaults for all paths, which is to create them under the same -directory configure is run in. - - There are several directories that Cbuildv2 needs. These are the -following: - - * local snapshots - This is where all the downloaded sources get - stored. The default is the current directory under snapshots. - * local build - This is where all the executables get built. The - default is to have builds go in a top level directory which is the - full hostname of the build machine. Under this a directory is - created for the target architecture. - * remote snapshots - This is where remote tarballs are stored. This - currently defaults to cbuild.validation.linaro.org, which is - accessible via HTTP to the general public. - - If configure is executed without any parameters. the defaults are -used. It is also possible to change those values at configure -time. For example: - -$CBUILD-PATH/configure ---with-local-snapshots=$CBUILD_PATH/snapshots ---with-local-builds=$CBUILD-PATH/destdir ---with-remote-snapshots=cbuild@toolchain64.lab:/home/cbuild/var/snapshots/ - - This changes the 3 primary paths, including changing the remote host -to use rsync or ssh to download tarballs instead of HTTP. You can -execute ./configure --help to get the full list of configure time -parameters. - - The configure process produces a host.conf file, with the default -settings. This file is read by cbuildv2 at runtime, so it's possible to -change the values and rerun cbuild2.sh to use the new values. Each -toolchain component also has a config file. The default version is -copied at build time to the build tree. It is also possible to edit -this file, usually called something like gcc.conf, to change the -toolchain component specific values used when configuring the -component. - - You can see what values were used to configure each component by -looking in the top of the config.log file, which is produced at -configure time. For example: - - head ${hostname}/${target}/${component}/config.log - -Default Behaviours: ------------------- - There are several behaviours that may not be obvious, so they're -documented here. One relates to GCC builds. When built natively, GCC -only builds itself once, and is fully functional. When cross -compiling, this works differently. A fully functional GCC can't be -built without a sysroot, so a minimum compiler is built to build the C -library. This is called stage1. This is then used to compiler the C -library. One this library is installed, then stage2 of GCC can be -built. - - When building an entire toolchain using the 'all' option to --build, -all components are built in the correct order, including both GCC -stages. It is possible to specify building only GCC, in this case the -stage1 configure flags are used if the C library isn't installed. If -the C library is installed, then the stage2 flags are used. A message -is displayed to document the automatic configure decision. - -Specifying the source works like this: -------------------------------------- -It's possible to specify a full tarball name, minus the compression -part, which will be found dynamically. If the word 'tar' appears in -the suppplied name, it's only looked for on the remote directory. If -the name is a URL for bzr, sv, http, or git, the the source are -instead checked out from a remote repository instead with the -appropriate source code control system. - -It's also possible to specify an 'alias', ie ... 'gcc-4.8' instead. In -this case, the remote snapshot directory is checked first. If the name -is not unique, but matches are found, and error is generated. If the -name isn't found at all, then a URL for the source repository is -extracted from the sources.conf file, and the code is checkout out. - -There are a few ways if listing the files to see what is -available. There ar two primary remote directories where files that -can be downloaded are stored. These are 'snapshots' or -'infrastructure'. Infrastructure is usualy only installed once per -host, and contains the other packages needed to build GCC, like -gmp. Snapshots is the primary location of all source tarballs. To list -all the available snapshots, you can do this" - - "cbuild2.sh --list snapshots". - -You can also run cbuildv2 with the --interactive options, which will -display a subset of all the packages that matches the supplied -string. To build a specific component, use the --build option to -cbuildv2. the --target option is also used for cross builds. For -example: - -"cbuild2.sh --target arm-none-linux-gnueabihf gcc-linaro-4.8.2013.07-1" - -This would fetch the source tarball for this release, build anything -it needs to compile, the binutils for example, and then build these -sources. You can also specify a URL to a source repository -instead. For example: - -"cbuild2.sh --target arm-none-linux-gnueabihf git://git.linaro.org/toolchain/eglibc.git" - -To build an entire cross toolchain, the simplest way is to let -cbuildv2 control all the steps. Although it is also possible to do each -step separately. To build the full toolchain, do this: - -"cbuild2.sh --target arm-none-linux-gnueabihf --build all" - ---------------------------------------------------------------------- -Older NOTES - -x86_64-none-linux-gnu -arm-none-linux-gnueabi -arm-none-linux-gnueabihf -armeb-none-linux-gnueabihf -aarch64-none-linux-gnu -aarch64-none-elf -aarch64_be-none-elf -aarch64_be-none-linux-gnu - -Toolchain Components - * gcc (gcc, g++, objc, fortran) - * gas - * ld (gold) - * libc (newlib,eglibc,glibc) - * dependant libs (gmp, mpc, mpfr, libelf) - -Build with stock Ubuntu toolchains - * Linaro GCC Maintenance (currently Linaro GCC 4.7) - * FSF GCC Previous (currently FSF GCC 4.7) - * FSF GCC Current (currently FSF GCC 4.8) - -Build with trunk/master - * Linaro GCC Development (currently Linaro GCC 4.8) - * FSF GCC Trunk (currently FSF GCC 4.9) - -Variables - * build machine toolchain versions of all components (gcc, gas, ld, libc) - * configure options - -Features: ---------- - * Build with downloaded binaries or build them all locally - * Has default configuration for all components - * All info recorded into an SQL database - * Ability to mix & match all toolchain components - * Test locally or remotely - * Queue jobs for LAVA - * Lists possible versions and components for build - -cbuild2 command line arguments: -------------------------------- - * --build (architecture for the build machine, default native) - * --target (architecture for the target machine, default native) - * --snapshots XXX (URL of remote host or local directory) - * --libc {newlib,eglibc,glibc} (C library to use) - * --list {gcc,binutils,libc} (list possible values for component versions) - * --set {gcc,binutils,libc,latest}=XXX (change config file setting) - * --binutils (binutils version to use, default $PATH) - * --gcc (gcc version to use, default $PATH) - * --config XXX (alternate config file) - * --clean (clean a previous build, default is to start where it left off) - * --dispatch (run on LAVA build farm, probably remote) - * --sysroot XXX (specify path to alternate sysroot) - - -General ideas -------------- -Use a shell script as config file, ala *.conf and set global -variables or custom functions. A good naming convention to avoid -collisions is important. It should be able to be download from a -remote host. - -Rather than Makefiles, it should use bourne shell scripts for more -functionality. Both Android and Chromium use this technique. - -Each project that needs to be built should have a file that lists it's -major build time dependancies. There should be defaults for all -targets, but values can be overridden with local config files. The -config data could also potentially live in a database. The config data -is recorded into the database for each build and test run. - -Cross building G++ is complex, there is a stage 1 build of the -compiler, which is only used to build the C library. Then the C -library is compiled. After that G++ can be built. - -Analysis --------- - -The main goal is to have the appropriate data accessible to support -charting it in various ways to assist in better understanding of the -quality of each toolchain component. This will assist developers in -determining if their changes improve or degrade the component's -quality. This will also allow others to get an overview of each -component's quality, which will support product releases and -management planning. - - * Plot a test run of a specific version of a component across all - supported platforms - * Plot a test case of a component across all supported platforms - * Plot a test case of a component across a list of versions - * Plot a component's PASS percentage across all supported platforms - * Plot a component's PASS percentage across all supported platforms - and several versions. - * Plot a component's FAIL percentage across all supported platforms - * Plot a component's FAIL percentage across all supported platforms - and several versions. - * Plot all test states as a percentage of total test results - * Plot all test states of the actual totals for each - * -CoreMark - * Compiler and version - * Operating Speed in Mhz - * CoreMark/Mhz - * CoreMark - * CoreMark/Core - * Parallel Execution - * EEMBC - -EEMBC - * TODO - -Spec CPU 2000 - * CINT - * Benchmark - * Reference Time - * Base Runtime - * Base Ratio - * Runtime - * Ratio - * CFP - * Benchmark - * Reference Time - * Base Runtime - * Base Ratio - * Runtime - * Ratio - -Spec CPU 2006 - * Benchmark - * Base Seconds - * Base Ratio - * Peak Seconds - * Peak Ratio - -Notes on Bourne Shell Scripting -------------------------------- - - These scripts use a few techniques in many places that relate to -shell functions. One is heavy use of bourne shell functions to reduce -duplication, and make the code better organized. Any string echo'd by -a function becomes it's return value. Bourne shell supports 2 types of -return values though. One is the string returned by the function. This -is used whenever the called function returns data. This is captured by -the normal shell commands like this: values="`call_function $1`". The -other type of return value is a single integer. Much like system -calls, these scripts all return 0 for success, and 1 for errors. This -enables the calling function to trap errors, and handle them in a -clean fashion. - - A few good habits to mention, always enclose a sub shell execution -in double quotes. If the returned string contains spaces, this -preserves the data, otherwise it'll get truncated. - - Another good habit is to always prepend a character when doing -string comparisons. If one of the two strings is undefined, the script -will abort. So always using "test x${foo} = xbar" prevents that. - +This project has been reamed and moved to: https://git.linaro.org/toolchain/abe.git |