05754fa01d
Some packages need a host-python interpreter with a version different from the one installed in the target to run some build scripts (eg. scons requires python2 to run, to build any kind of packages even if the python interpreter selected for the target is python3). In such cases, we need to add the right host-python dependency to the package using the host-python-package infrastructure, and we also want to invoke the right host python interpreter during the build steps. This patch adds a *_NEEDS_HOST_PYTHON variable that can be set either to 'python2' or 'python3'. This variable can be set by any package using the host-python-package infrastructure to force the python interpreter for the build. This variable also takes care of setting the right host-python dependency. This *_NEEDS_HOST_PYTHON variable only affects packages using the host-python-package infrastructure. If some configure/build/install commands are overloaded in the *.mk file, the right python interpreter should be explicitly called. If the package defines some tool variable (eg.: SCONS), the variable should explicitly call the right python interpreter. [Thomas: - fixes to the commit log and documentation suggested by Yann - rename the variable from <pkg>_FORCE_HOST_PYTHON to <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann - do not allow any other value than python2 and python3 in <pkg>_NEEDS_HOST_PYTHON, as suggested by Yann.] Signed-off-by: Samuel Martin <s.martin49@gmail.com> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.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