19afad50f5
DL_DIR can be a very precious place for some users: they use it to store all the downloaded archives to share across all their Buildroot (and maybe non-Buildroot) builds. We do not want to trash this location with our temporary downloads (e.g. git, Hg, svn, cvs repository clones/checkouts, or wget, bzr tep tarballs). Turns out that we already have some kind of scratchpad, the BUILD_DIR. Although it is not really a disposable location, that's the best we have so far. Also, we create the temporary tarballs with mktemp using the final tarball, as template, since we want the temporary to be on the same filesystem as the final location, so the 'mv' is just a plain, atomic rename(2), and we are not left with a half-copied file as the final location. Using mktemp ensures all temp file names are unique, so it allows for parallel downloads from different build dirs at the same time, without cloberring each downloads. Note: we're using neither ${TMP} nor ${TMPDIR} since they are shared locations, sometime with little place (eg. tmpfs), and some of the repositories we clone/checkout can be very big. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Samuel Martin <s.martin49@gmail.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Tested-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> [tested a particular scenario that used to fail: two separate builds using a shared DL_DIR, ccache enabled, so that they run almost synchronously. These would download the same file at the same time, corrupting each other. With the patches in this series, all works fine.] Signed-off-by: Peter Korsgaard <peter@korsgaard.com> |
||
---|---|---|
arch | ||
board | ||
boot | ||
configs | ||
docs | ||
fs | ||
linux | ||
package | ||
support | ||
system | ||
toolchain | ||
.defconfig | ||
.gitignore | ||
CHANGES | ||
Config.in | ||
Config.in.legacy | ||
COPYING | ||
Makefile | ||
Makefile.legacy | ||
README |
To build and use the buildroot stuff, do the following: 1) run 'make menuconfig' 2) select the packages you wish to compile 3) run 'make' 4) wait while it compiles 5) Use your shiny new root filesystem. Depending on which sort of root filesystem you selected, you may want to loop mount it, chroot into it, nfs mount it on your target device, burn it to flash, or whatever is appropriate for your target system. You do not need to be root to build or run buildroot. Have fun! Offline build: ============== In order to do an offline-build (not connected to the net), fetch all selected source by issuing a $ make source before you disconnect. If your build-host is never connected, then you have to copy buildroot and your toplevel .config to a machine that has an internet-connection and issue "make source" there, then copy the content of your dl/ dir to the build-host. Building out-of-tree: ===================== Buildroot supports building out of tree with a syntax similar to the Linux kernel. To use it, add O=<directory> to the make command line, E.G.: $ make O=/tmp/build And all the output files (including .config) will be located under /tmp/build. More finegrained configuration: =============================== You can specify a config-file for uClibc: $ make UCLIBC_CONFIG_FILE=/my/uClibc.config And you can specify a config-file for busybox: $ make BUSYBOX_CONFIG_FILE=/my/busybox.config To use a non-standard host-compiler (if you do not have 'gcc'), make sure that the compiler is in your PATH and that the library paths are setup properly, if your compiler is built dynamically: $ make HOSTCC=gcc-4.3.orig HOSTCXX=gcc-4.3-mine Depending on your configuration, there are some targets you can use to use menuconfig of certain packages. This includes: $ make HOSTCC=gcc-4.3 linux-menuconfig $ make HOSTCC=gcc-4.3 uclibc-menuconfig $ make HOSTCC=gcc-4.3 busybox-menuconfig Please feed suggestions, bug reports, insults, and bribes back to the buildroot mailing list: buildroot@buildroot.org