7430a41801
The linux package has a special handling of patches, with quite a bit of legacy in it. A problem caused by this special handling is that the linux package calls directly the DOWNLOAD_WGET macro, which means that the package infrastructure isn't aware of which patches get downloaded, and it prevents doing changes inside the package download infrastructure. This commit changes the handling of patches in the linux package in the following way: * The LINUX_PATCHES variable is kept as is: it lists all the patches mentioned in the Config.in option BR2_LINUX_KERNEL_PATCH. This option can contain http://, ftp://, https:// URLs, path to local files or local directories. This variable is *not* used by the generic package infrastructure, so it is purely internal to the Linux package. * The LINUX_PATCH variable is now filled in with the list of patches that should be downloaded. It is derived from LINUX_PATCHES by filtering the patches that have http://, ftp:// or https:// in their path. Since <pkg>_PATCH is handled by the package infrastructure, it means that those patches are now automatically downloaded and applied by the package infrastructure. * The LINUX_APPLY_PATCHES hook is renamed to LINUX_APPLY_LOCAL_PATCHES, because it is now only responsible of applying local patches: remote patches are handled by LINUX_PATCH. The implementation of the hook is changed to filter out the patches that have already taken care of by LINUX_PATCH, so that we only iterate through the list of local patches or local patch directories. [Thomas: adjust comment in the code according to Yann comments.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Romain Naour <romain.naour@openwide.fr> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr> |
||
|---|---|---|
| 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