<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/scripts/Makefile.lib, branch v5.4.300</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.300</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.300'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2025-07-17T16:24:51Z</updated>
<entry>
<title>kbuild: use -MMD instead of -MD to exclude system headers from dependency</title>
<updated>2025-07-17T16:24:51Z</updated>
<author>
<name>Masahiro Yamada</name>
<email>masahiroy@kernel.org</email>
</author>
<published>2020-04-23T14:23:53Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=445164274701b21fc1589ff62e92b38580afa5ce'/>
<id>urn:sha1:445164274701b21fc1589ff62e92b38580afa5ce</id>
<content type='text'>
[ Upstream commit 30a7729771731971839cc969d2a321e6ea7a144b ]

This omits system headers from the generated header dependency.

System headers are not updated unless you upgrade the compiler. Nor do
they contain CONFIG options, so fixdep does not need to parse them.

Having said that, the effect of this optimization will be quite small
because the kernel code generally does not include system headers
except &lt;stdarg.h&gt;. Host programs include a lot of system headers,
but there are not so many in the kernel tree.

At first, keeping system headers in .*.cmd files might be useful to
detect the compiler update, but there is no guarantee that &lt;stdarg.h&gt;
is included from every file. So, I implemented a more reliable way in
the previous commit.

Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Stable-dep-of: 02e9a22ceef0 ("kbuild: hdrcheck: fix cross build with clang")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>kbuild: fix broken builds because of GZIP,BZIP2,LZOP variables</title>
<updated>2020-09-03T09:27:10Z</updated>
<author>
<name>Denis Efremov</name>
<email>efremov@linux.com</email>
</author>
<published>2020-06-08T09:59:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c98b6ebd9b555db3ddc7751d31e5e424c1c81245'/>
<id>urn:sha1:c98b6ebd9b555db3ddc7751d31e5e424c1c81245</id>
<content type='text'>
commit e4a42c82e943b97ce124539fcd7a47445b43fa0d upstream.

Redefine GZIP, BZIP2, LZOP variables as KGZIP, KBZIP2, KLZOP resp.
GZIP, BZIP2, LZOP env variables are reserved by the tools. The original
attempt to redefine them internally doesn't work in makefiles/scripts
intercall scenarios, e.g., "make GZIP=gzip bindeb-pkg" and results in
broken builds. There can be other broken build commands because of this,
so the universal solution is to use non-reserved env variables for the
compression tools.

Fixes: 8dfb61dcbace ("kbuild: add variables for compression tools")
Signed-off-by: Denis Efremov &lt;efremov@linux.com&gt;
Tested-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Cc: Matthias Maennich &lt;maennich@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>kbuild: add variables for compression tools</title>
<updated>2020-09-03T09:27:10Z</updated>
<author>
<name>Denis Efremov</name>
<email>efremov@linux.com</email>
</author>
<published>2020-06-05T07:39:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=37432a83faab68c0bc89d6a4395ff063eaa14f3b'/>
<id>urn:sha1:37432a83faab68c0bc89d6a4395ff063eaa14f3b</id>
<content type='text'>
commit 8dfb61dcbaceb19a5ded5e9c9dcf8d05acc32294 upstream.

Allow user to use alternative implementations of compression tools,
such as pigz, pbzip2, pxz. For example, multi-threaded tools to
speed up the build:
$ make GZIP=pigz BZIP2=pbzip2

Variables _GZIP, _BZIP2, _LZOP are used internally because original env
vars are reserved by the tools. The use of GZIP in gzip tool is obsolete
since 2015. However, alternative implementations (e.g., pigz) still rely
on it. BZIP2, BZIP, LZOP vars are not obsolescent.

The credit goes to @grsecurity.

As a sidenote, for multi-threaded lzma, xz compression one can use:
$ export XZ_OPT="--threads=0"

Signed-off-by: Denis Efremov &lt;efremov@linux.com&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Signed-off-by: Matthias Maennich &lt;maennich@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>kbuild: fix DT binding schema rule again to avoid needless rebuilds</title>
<updated>2020-05-02T06:48:42Z</updated>
<author>
<name>Masahiro Yamada</name>
<email>masahiroy@kernel.org</email>
</author>
<published>2020-04-21T03:35:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8f4cd6f0ea8278ded04145f6034ea7c7f3681fae'/>
<id>urn:sha1:8f4cd6f0ea8278ded04145f6034ea7c7f3681fae</id>
<content type='text'>
commit 3d4b2238684ac919394eba7fb51bb7eeeec6ab57 upstream.

Since commit 7a0496056064 ("kbuild: fix DT binding schema rule to detect
command line changes"), this rule is every time re-run even if you change
nothing.

cmd_dtc takes one additional parameter to pass to the -O option of dtc.

We need to pass 'yaml' to if_changed_rule. Otherwise, cmd-check invoked
from if_changed_rule is false positive.

Fixes: 7a0496056064 ("kbuild: fix DT binding schema rule to detect command line changes")
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>kbuild: remove header compile test</title>
<updated>2020-03-05T15:43:47Z</updated>
<author>
<name>Masahiro Yamada</name>
<email>yamada.masahiro@socionext.com</email>
</author>
<published>2019-11-07T07:14:40Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ef134d8b493c537b81e8cbd56704efff0b402d8a'/>
<id>urn:sha1:ef134d8b493c537b81e8cbd56704efff0b402d8a</id>
<content type='text'>
commit fcbb8461fd2376ba3782b5b8bd440c929b8e4980 upstream.

There are both positive and negative options about this feature.
At first, I thought it was a good idea, but actually Linus stated a
negative opinion (https://lkml.org/lkml/2019/9/29/227). I admit it
is ugly and annoying.

The baseline I'd like to keep is the compile-test of uapi headers.
(Otherwise, kernel developers have no way to ensure the correctness
of the exported headers.)

I will maintain a small build rule in usr/include/Makefile.
Remove the other header test functionality.

Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
[ added to 5.4.y due to start of build warnings from backported patches
  because of this feature - gregkh]
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>kbuild: fix DT binding schema rule to detect command line changes</title>
<updated>2020-03-05T15:43:46Z</updated>
<author>
<name>Masahiro Yamada</name>
<email>masahiroy@kernel.org</email>
</author>
<published>2020-02-22T19:04:31Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f5cfa47505ac4424e3d89843dddc522beb2bafe0'/>
<id>urn:sha1:f5cfa47505ac4424e3d89843dddc522beb2bafe0</id>
<content type='text'>
commit 7a04960560640ac5b0b89461f7757322b57d0c7a upstream.

This if_change_rule is not working properly; it cannot detect any
command line change.

The reason is because cmd-check in scripts/Kbuild.include compares
$(cmd_$@) and $(cmd_$1), but cmd_dtc_dt_yaml does not exist here.

For if_change_rule to work properly, the stem part of cmd_* and rule_*
must match. Because this cmd_and_fixdep invokes cmd_dtc, this rule must
be named rule_dtc.

Fixes: 4f0e3a57d6eb ("kbuild: Add support for DT binding schema checks")
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Acked-by: Rob Herring &lt;robh@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>kbuild: remove ar-option and KBUILD_ARFLAGS</title>
<updated>2019-10-01T00:20:33Z</updated>
<author>
<name>Masahiro Yamada</name>
<email>yamada.masahiro@socionext.com</email>
</author>
<published>2019-09-21T06:49:54Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=13dc8c029cabf52ba95f60c56eb104d4d95d5889'/>
<id>urn:sha1:13dc8c029cabf52ba95f60c56eb104d4d95d5889</id>
<content type='text'>
Commit 40df759e2b9e ("kbuild: Fix build with binutils &lt;= 2.19")
introduced ar-option and KBUILD_ARFLAGS to deal with old binutils.

According to Documentation/process/changes.rst, the current minimal
supported version of binutils is 2.21 so you can assume the 'D' option
is always supported. Not only GNU ar but also llvm-ar supports it.

With the 'D' option hard-coded, there is no more user of ar-option
or KBUILD_ARFLAGS.

Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Reviewed-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Tested-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
</content>
</entry>
<entry>
<title>kbuild: rename KBUILD_ENABLE_EXTRA_GCC_CHECKS to KBUILD_EXTRA_WARN</title>
<updated>2019-09-06T14:46:52Z</updated>
<author>
<name>Masahiro Yamada</name>
<email>yamada.masahiro@socionext.com</email>
</author>
<published>2019-08-31T16:25:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e27128db62834c5b906585c2d97f0ddd431fa28f'/>
<id>urn:sha1:e27128db62834c5b906585c2d97f0ddd431fa28f</id>
<content type='text'>
KBUILD_ENABLE_EXTRA_GCC_CHECKS started as a switch to add extra warning
options for GCC, but now it is a historical misnomer since we use it
also for Clang, DTC, and even kernel-doc.

Rename it to more sensible, shorter KBUILD_EXTRA_WARN.

For the backward compatibility, KBUILD_ENABLE_EXTRA_GCC_CHECKS is still
supported (but not advertised in the documentation).

I also fixed up 'make help', and updated the documentation.

Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Reviewed-by: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Reviewed-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Reviewed-by: Sedat Dilek &lt;sedat.dilek@gmail.com&gt;
</content>
</entry>
<entry>
<title>kbuild: change *FLAGS_&lt;basetarget&gt;.o to take the path relative to $(obj)</title>
<updated>2019-09-04T14:12:50Z</updated>
<author>
<name>Masahiro Yamada</name>
<email>yamada.masahiro@socionext.com</email>
</author>
<published>2019-08-30T04:34:01Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=54b8ae66ae1a3454a7645d159a482c31cd89ab33'/>
<id>urn:sha1:54b8ae66ae1a3454a7645d159a482c31cd89ab33</id>
<content type='text'>
Kbuild provides per-file compiler flag addition/removal:

  CFLAGS_&lt;basetarget&gt;.o
  CFLAGS_REMOVE_&lt;basetarget&gt;.o
  AFLAGS_&lt;basetarget&gt;.o
  AFLAGS_REMOVE_&lt;basetarget&gt;.o
  CPPFLAGS_&lt;basetarget&gt;.lds
  HOSTCFLAGS_&lt;basetarget&gt;.o
  HOSTCXXFLAGS_&lt;basetarget&gt;.o

The &lt;basetarget&gt; is the filename of the target with its directory and
suffix stripped.

This syntax comes into a trouble when two files with the same basename
appear in one Makefile, for example:

  obj-y += foo.o
  obj-y += dir/foo.o
  CFLAGS_foo.o := &lt;some-flags&gt;

Here, the &lt;some-flags&gt; applies to both foo.o and dir/foo.o

The real world problem is:

  scripts/kconfig/util.c
  scripts/kconfig/lxdialog/util.c

Both files are compiled into scripts/kconfig/mconf, but only the
latter should be given with the ncurses flags.

It is more sensible to use the relative path to the Makefile, like this:

  obj-y += foo.o
  CFLAGS_foo.o := &lt;some-flags&gt;
  obj-y += dir/foo.o
  CFLAGS_dir/foo.o := &lt;other-flags&gt;

At first, I attempted to replace $(basetarget) with $*. The $* variable
is replaced with the stem ('%') part in a pattern rule. This works with
most of cases, but does not for explicit rules.

For example, arch/ia64/lib/Makefile reuses rule_as_o_S in its own
explicit rules, so $* will be empty, resulting in ignoring the per-file
AFLAGS.

I introduced a new variable, target-stem, which can be used also from
explicit rules.

Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Acked-by: Marc Zyngier &lt;maz@kernel.org&gt;
</content>
</entry>
<entry>
<title>kbuild: add $(BASH) to run scripts with bash-extension</title>
<updated>2019-09-04T13:54:13Z</updated>
<author>
<name>Masahiro Yamada</name>
<email>yamada.masahiro@socionext.com</email>
</author>
<published>2019-08-25T13:28:37Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=858805b336be1cabb3d9033adaa3676574d12e37'/>
<id>urn:sha1:858805b336be1cabb3d9033adaa3676574d12e37</id>
<content type='text'>
CONFIG_SHELL falls back to sh when bash is not installed on the system,
but nobody is testing such a case since bash is usually installed.
So, shell scripts invoked by CONFIG_SHELL are only tested with bash.

It makes it difficult to test whether the hashbang #!/bin/sh is real.
For example, #!/bin/sh in arch/powerpc/kernel/prom_init_check.sh is
false. (I fixed it up)

Besides, some shell scripts invoked by CONFIG_SHELL use bash-extension
and #!/bin/bash is specified as the hashbang, while CONFIG_SHELL may
not always be set to bash.

Probably, the right thing to do is to introduce BASH, which is bash by
default, and always set CONFIG_SHELL to sh. Replace $(CONFIG_SHELL)
with $(BASH) for bash scripts.

If somebody tries to add bash-extension to a #!/bin/sh script, it will
be caught in testing because /bin/sh is a symlink to dash on some major
distributions.

Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
</content>
</entry>
</feed>
