diff options
| author | Masahiro Yamada <yamada.masahiro@socionext.com> | 2019-06-04 13:14:02 +0300 |
|---|---|---|
| committer | Masahiro Yamada <yamada.masahiro@socionext.com> | 2019-06-15 13:57:02 +0300 |
| commit | 59b2bd05f5f4dc62979c2e82ddd384f07e8f10bc (patch) | |
| tree | ebb1a1d1d41a40074c3baab8fc0135ad4031abf3 /lib/Kconfig.debug | |
| parent | bdd7714b6f4cca75dd1b234306077150060c2f45 (diff) | |
| download | linux-59b2bd05f5f4dc62979c2e82ddd384f07e8f10bc.tar.xz | |
kbuild: add 'headers' target to build up uapi headers in usr/include
In Linux build system, build targets and installation targets are
separated.
Examples are:
- 'make vmlinux' -> 'make install'
- 'make modules' -> 'make modules_install'
- 'make dtbs' -> 'make dtbs_install'
- 'make vdso' -> 'make vdso_install'
The intention is to run the build targets under the normal privilege,
then the installation targets under the root privilege since we need
the write permission to the system directories.
We have 'make headers_install' but the corresponding 'make headers'
stage does not exist. The purpose of headers_install is to provide
the kernel interface to C library. So, nobody would try to install
headers to /usr/include directly.
If 'sudo make INSTALL_HDR_PATH=/usr/include headers_install' were run,
some build artifacts in the kernel tree would be owned by root because
some of uapi headers are generated by 'uapi-asm-generic', 'archheaders'
targets.
Anyway, I believe it makes sense to split the header installation into
two stages.
[1] 'make headers'
Process headers in uapi directories by scripts/headers_install.sh
and copy them to usr/include
[2] 'make headers_install'
Copy '*.h' verbatim from usr/include to $(INSTALL_HDR_PATH)/include
For the backward compatibility, 'headers_install' depends on 'headers'.
Some samples expect uapi headers in usr/include. So, the 'headers'
target is useful to build up them in the fixed location usr/include
irrespective of INSTALL_HDR_PATH.
Another benefit is to stop polluting the final destination with the
time-stamp files '.install' and '.check'. Maybe you can see them in
your toolchains.
Lastly, my main motivation is to prepare for compile-testing uapi
headers. To build something, we have to save an object and .*.cmd
somewhere. The usr/include/ will be the work directory for that.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Diffstat (limited to 'lib/Kconfig.debug')
| -rw-r--r-- | lib/Kconfig.debug | 4 |
1 files changed, 1 insertions, 3 deletions
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 6a6ea4219d1e..0031a31d98c2 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -324,9 +324,7 @@ config HEADERS_CHECK attempt to include files which were not exported, etc. If you're making modifications to header files which are - relevant for userspace, say 'Y', and check the headers - exported to $(INSTALL_HDR_PATH) (usually 'usr/include' in - your build tree), to make sure they're suitable. + relevant for userspace, say 'Y'. config OPTIMIZE_INLINING bool "Allow compiler to uninline functions marked 'inline'" |