8b8a60cd52
In the sequence: make uclibc-menuconfig make uclibc-update-config the freshly configured settings from the menuconfig are lost during the update-config step. This is because update-config depends on the configure step, which starts by copying the config file to the build directory. Instead, stop depending on the configure step from update-config, and introduce a new stamp file .stamp_config_fixup_done, which applies any fixups on the .config file. An alternative solution would be to add a call to UCLIBC_FIXUP_DOT_CONFIG to the relevant targets instead of depending on a new stamp file. The advantage of the stamp file, though, is that we avoid redoing the fixup unnecessarily. Moreover, in the light of the plan to extract the kconfig-specific bits into a separate kconfig-package infrastructure, the stamp file rules are more easily moved into such an infrastructure, while the alternative solution requires the package .mk file to explicitly call the FIXUP rules which may more easily be forgotten. No longer depending on the configure step has the added bonus that 'uclibc-update-config' no longer needs the toolchain to be available, which makes: make clean uclibc-menuconfig uclibc-update-config much faster and user-friendly. Additionally, make sure that 'make clean uclibc-update-config' works properly, by depending on .stamp_config_fixup_done so that the config file is present and fixed. Fixes bug #7154 https://bugs.busybox.net/show_bug.cgi?id=7154 Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.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