29 Aug, 2019
3 commits
-
Remove some variables.
Signed-off-by: Masahiro Yamada
-
This '+' was added a long time ago:
| commit c23e6bf05f7802e92fd3da69a1ed35e56f9c85bb (HEAD)
| Author: Kai Germaschewski
| Date: Mon Oct 28 01:16:34 2002 -0600
|
| kbuild: Fix a "make -j" warning
|
| diff --git a/scripts/Makefile.clean b/scripts/Makefile.clean
| index 2c843e0380bc..e7c392fd5788 100644
| --- a/scripts/Makefile.clean
| +++ b/scripts/Makefile.clean
| @@ -42,7 +42,7 @@ quiet_cmd_clean = CLEAN $(obj)
|
| __clean: $(subdir-ymn)
| ifneq ($(strip $(__clean-files) $(clean-rule)),)
| - $(call cmd,clean)
| + +$(call cmd,clean)
| else
| @:
| endifAt that time, cmd_clean contained $(clean-rule), which was able to
invoke sub-make. That was why cleaning with the -j option showed:
warning: jobserver unavailable: using -j1. Add '+' to parent make rule.It is not the case any more; cmd_clean now just runs the 'rm' command.
The '+' marker is pointless.Signed-off-by: Masahiro Yamada
-
The only the difference between clean-files and clean-dirs is the -r
option passed to the 'rm' command.You can always pass -r, and then remove the clean-dirs syntax.
Signed-off-by: Masahiro Yamada
09 Aug, 2018
1 commit
-
The host-progs has been kept as an alias of hostprogs-y for a long time
(at least since the beginning of Git era), with the clear prompt:
Usage of host-progs is deprecated. Please replace with hostprogs-y!Enough time for the migration has passed.
Signed-off-by: Masahiro Yamada
Acked-by: Max Filippov
06 Jul, 2018
1 commit
-
The comment is the same as in the top-level Makefile.
Also, the comments contain typos:
- the .PHONY variable -> the PHONY variable
- se we can ... -> so we can ...Instead of fixing the typos, just remove the duplicated comments.
Signed-off-by: Masahiro Yamada
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
08 Jun, 2016
1 commit
-
Infrastructure for building independent shared library targets.
Based on work created by the PaX Team.
Signed-off-by: Emese Revfy
Acked-by: Kees Cook
Signed-off-by: Michal Marek
20 Feb, 2015
1 commit
-
Pull kbuild updates from Michal Marek:
- several cleanups in kbuild
- serialize multiple *config targets so that 'make defconfig kvmconfig'
works- The cc-ifversion macro got support for an else-branch
* 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
kbuild,gcov: simplify kernel/gcov/Makefile more
kbuild: allow cc-ifversion to have the argument for false condition
kbuild,gcov: simplify kernel/gcov/Makefile
kbuild,gcov: remove unnecessary workaround
kbuild: do not add $(call ...) to invoke cc-version or cc-fullversion
kbuild: fix cc-ifversion macro
kbuild: drop $(version_h) from MRPROPER_FILES
kbuild: use mixed-targets when two or more config targets are given
kbuild: remove redundant line from bounds.h/asm-offsets.h
kbuild: merge bounds.h and asm-offsets.h rules
kbuild: Drop support for clean-rule
02 Jan, 2015
2 commits
-
scripts/Makefile.clean treats absolute path specially, but
$(objtree)/debian is no longer an absolute path since 7e1c0477 (kbuild:
Use relative path for $(objtree). Work around this by checking if the
path starts with $(objtree)/.Reported-and-tested-by: Sedat Dilek
Fixes: 7e1c0477 (kbuild: Use relative path for $(objtree)
Signed-off-by: Michal Marek -
clean-rule has not been used since 94869f86 (kbuild: Accept absolute
paths in clean-files and introduce clean-dirs) ten years ago.Tested-by: Sedat Dilek
Signed-off-by: Michal Marek
26 Nov, 2014
2 commits
-
Makefile.clean includes Kbuild.include since commit 371fdc77
(kbuild: collect shorthands into scripts/Kbuild.include), so there is no
need for a local copy.Signed-off-by: Michal Marek
-
The shorthand "clean" is defined in both the top Makefile and
scripts/Makefile.clean. Likewise, the "hdr-inst" is defined in
both the top Makefile and scripts/Makefile.headersinst.To reduce code duplication, this commit collects them into
scripts/Kbuild.include like the "build" and "modbuiltin" shorthands.
It requires scripts/Makefile.clean to include scripts/Kbuild.include,
but its impact on the performance of "make clean" should be
negligible.Signed-off-by: Masahiro Yamada
Signed-off-by: Michal Marek
02 Oct, 2014
2 commits
-
$(if $(KBUILD_SRC),$(srctree)/) was a useful strategy
to omit a long absolute path for in-source-tree build
prior to commit 890676c65d699db3ad82e7dddd0cf8fb449031af
(kbuild: Use relative path when building in the source tree).Now $(srctree) is "." when building in the source tree.
It would not be annoying to add "$(srctree)/" all the time.Signed-off-by: Masahiro Yamada
Signed-off-by: Michal Marek -
Kconfig never defines CONFIG_* as 'n'.
Now obj-n is only used in firmware/Makefile and it can be
replaced with obj-. No makefile uses lib-n.Let's rip off obj-n and lib-n.
Signed-off-by: Masahiro Yamada
Acked-by: Peter Foley
Signed-off-by: Michal Marek
04 Jul, 2014
1 commit
-
Signed-off-by: Masahiro Yamada
Signed-off-by: Michal Marek
11 Mar, 2010
1 commit
-
Commit 7d3cc8b tried to keep bounds.h and asm-offsets.h during make
clean by filtering these out of $(clean-files), but they are listed in
$(targets) and $(always) and thus removed automatically. Introduce a new
$(no-clean-files) variable to really skip such files in Makefile.clean.Signed-off-by: Michal Marek
26 Apr, 2008
1 commit
-
Signed-off-by: Robert P. J. Day
Signed-off-by: Sam Ravnborg
13 Oct, 2007
1 commit
-
These checks has been present for several kernel releases (> 5).
So lets just get rid of them.
With this we no longer check for use of:
EXTRA_TARGETS, O_TARGET, L_TARGET, list-multi, export-objsThere were three remaining in-tree users of O_TARGET in some
unmaintained sh64 code - mail sent to the maintainer + list.Signed-off-by: Sam Ravnborg
06 Mar, 2006
1 commit
-
The kbuild system takes advantage of an incorrect behavior in GNU make.
Once this behavior is fixed, all files in the kernel rebuild every time,
even if nothing has changed. This patch ensures kbuild works with both
the incorrect and correct behaviors of GNU make.For more details on the incorrect behavior, see:
http://lists.gnu.org/archive/html/bug-make/2006-03/msg00003.html
Changes in this patch:
- Keep all targets that are to be marked .PHONY in a variable, PHONY.
- Add .PHONY: $(PHONY) to mark them properly.
- Remove any $(PHONY) files from the $? list when determining whether
targets are up-to-date or not.Signed-off-by: Paul Smith
Signed-off-by: Sam Ravnborg
28 Jul, 2005
1 commit
-
kbuild failed to locate Makefile for external modules.
This brought to my attention how the variables for directories
have different values in different usage scenarios.Different kbuild usage scenarios:
make - plain make in same directory where kernel source lives
make O= - kbuild is told to store output files in another directory
make M= - building an external module
make O= M= - building an external module with kernel output seperate from srcValue assigned to the different variables:
|$(src) |$(obj) |$(srctree) |$(objtree)
make |reldir to k src |as src |abs path to k src |abs path to k src
make O= |reldir to k src |as src |abs path to k src |abs path to output dir
make M= |abs path to src |as src |abs path to k src |abs path to k src
make O= M= |abs path to src |as src |abs path to k src |abs path to k outputpath to kbuild file:
make | $(srctree)/$(src), $(src)
make O= | $(srctree)/$(src)
make M= | $(src)
make O= M= | $(src)From the table above it can be seen that the only good way to find the
home directory of the kbuild file is to locate the one of the two variants
that is an absolute path. If $(src) is an absolute path (starts with /)
then use it, otherwise prefix $(src) with $(srctree).Signed-off-by: Sam Ravnborg
26 Jul, 2005
2 commits
-
Defining clean before including the kbuild file give us knowledge when
the kbuild file is included for cleaning. This is rarey usefull - but in
a corner case in klibc this proved necessary.Signed-off-by: Sam Ravnborg
--- -
kbuild failed to locate Kbuild.include.
Teach kbuild how to find Kbuild files when using make O=...Signed-off-by: Sam Ravnborg
---
17 Apr, 2005
1 commit
-
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.Let it rip!
