summaryrefslogtreecommitdiff
path: root/lib
diff options
context:
space:
mode:
authorMasahiro Yamada <yamada.masahiro@socionext.com>2019-06-04 13:14:02 +0300
committerMasahiro Yamada <yamada.masahiro@socionext.com>2019-06-15 13:57:02 +0300
commit59b2bd05f5f4dc62979c2e82ddd384f07e8f10bc (patch)
treeebb1a1d1d41a40074c3baab8fc0135ad4031abf3 /lib
parentbdd7714b6f4cca75dd1b234306077150060c2f45 (diff)
downloadlinux-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')
-rw-r--r--lib/Kconfig.debug4
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'"