Example usage:
For kernels that need to run dtbTool after make.
Create a script named post-make.sh in the kernel source directory:
#!/bin/sh
dtbTool -s 2048 -p "${srcdir}/scripts/dtc/" -o \
"${builddir}/arch/arm/boot/dt.img" \
"${builddir}/arch/arm/boot"
To run this script inside the chroot:
$ source ~/pmbootstrap/helpers/envkernel.sh
$ make lineageos_bacon_defconfig
$ make
$ run-script post-make.sh
When there is already another kernel source path mounted then the old mount
should be removed. Otherwise the mount source will still be pointed at the
old kernel source.
When kbuild is using a separate directory for output files then it will
check if the kernel source directory is clean.
The build will throw an error when the source directory is not clean:
.. is not clean, please run 'make mrproper'
Once envkernel.sh has aliased the make command then make mrproper will
be run in the context of .output directory. If the source directory is not
clean then user may be wondering why make mrproper doesn't clean it.
This change will ensure that the source directory is clean when envkernel
is setup.
The pmbootstrap alias cannot be used within the script.
The reason is that aliases are not expanded in non-interactive shells.
reference: https://unix.stackexchange.com/q/1496
To fix this replace references to the pmbootstrap alias with
the $pmbootstrap variable
Changes:
* `helpers/envkernel.sh`:
* installs everything needed for kernel compilation in the native
chroot
* mounts the kernel source to `/mnt/linux` inside the chroot
* creates `/mnt/linux/.output` and chowns it to the `pmos` user, that
folder will be used for the kernel build output
* sets up aliases for `make`, `pmbootstrap`, `pmbroot`, `kernelroot`
* new action `pmbootstrap work_migrate`: does the interactive work
folder migration if necessary, otherwise it doesn't output anything
* when calling this first, we can safely use all other commands
non-interactively without showing the output
Benefits:
* Fast setup (especially for people who are new to kernel
compilation
* No need to figure out distribution specific package names
(cross compilers!)
* No need to do a test build just to verify that the right
packages are installed
* Less error prone
* The right dependencies are always installed
* `ARCH` and `CROSS_COMPILE` variables always get set automatically
and based on `deviceinfo_arch`
* If the build environment is broken for some reason, just zap and
start over
* Easy to reproduce problems
Notes:
* `make menuconfig` works as well
* Sourcing was tested with `zsh`, `bash` and `fish`, it should be easy to
extend for other shells
Robert Yang
Konrad Dybcio
Oliver Smith