29 Aug, 2019
1 commit
-
Both relative path and absolute path have pros and cons. For example,
we can move the source and objtree around together by using the
relative path to the source tree.Do not force the absolute path to the source tree. If you prefer the
absolute path, you can specify KBUILD_ABS_SRCTREE=1.Signed-off-by: Masahiro Yamada
02 Apr, 2019
2 commits
-
Now that Kbuild is able to start from any directory, the generated
Makefile can simply wrap the top Makefile.Signed-off-by: Masahiro Yamada
Reviewed-by: Kieran Bingham -
This hunk was added to avoid accidental overwrite of the top Makefile
in case O= points to the top of the source tree.As commit 4f1127e20437 ("kbuild: fix infinite make recursion"),
it caused some troubles in the past because Kbuild assumes O=
as out-of-tree build, while it actually works in the source tree.Now this works more properly; if O= points to the source directory,
it is handled as in-tree build. So, this sanity check is unneeded.Signed-off-by: Masahiro Yamada
04 Oct, 2018
4 commits
-
Assuming we never invoke the generated Makefile from outside of
the $(objtree) directory, $(CURDIR) points to the absolute path
of $(objtree).BTW, 'lastword' is natively supported by GNU Make 3.81+, which
is the current requirement for building the kernel.Signed-off-by: Masahiro Yamada
-
Since $(objtree) is always '.', it is not useful to pass it to
scripts/mkmakefile. I assume nobody wants to run this script directly.Signed-off-by: Masahiro Yamada
-
This line was added by commit fd5f0cd6b0ce ("kbuild: Do not overwrite
makefile as anohter user"). Its commit description says the intention
was to prevent $(objtree)/Makefile from being owned by root when e.g.
running 'make install'.However, as commit 19514fc665ff ("arm, kbuild: make "make install" not
depend on vmlinux") stated, installation targets must not modify the
source tree in the first place. If they do, we are already screwed up.
We must fix the root cause.Installation targets should just copy files verbatim, hence we never
expect $(objtree)/Makefile is touched by root. The user ID check in
scripts/mkmakefile is unneeded.Signed-off-by: Masahiro Yamada
-
Neither VERSION nor PATCHLEVEL is used in any useful way.
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
20 Aug, 2014
1 commit
-
The Makefiles call the respective interpreter explicitly, but this makes
it easier to use the scripts manually.Signed-off-by: Michal Marek
30 Apr, 2014
1 commit
-
Kbuild is supposed to support mixed targets. (%config and build targets)
But "make all" did nothing if it was run with configuration targets.
For example,$ LANG=C make defconfig all
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/zconf.lex.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
*** Default configuration is based on 'x86_64_defconfig'
#
# configuration written to .config
#
make: Nothing to be done for `all'.This commits allows "make %config all" and makes sure
mixed targets are built one by one in the given order.Signed-off-by: Masahiro Yamada
Cc: Michal Marek
CC: Sam Ravnborg
Signed-off-by: Michal Marek
20 Jul, 2011
1 commit
-
This patch silences the "make -C /usr/src/git O=/usr/src/git/build/."
message shown when using the generated makefile in KBUILD_OUTDIR.Signed-off-by: Peter Foley
Signed-off-by: Michal Marek
17 Aug, 2010
1 commit
-
It doesn't like pattern and explicit rules to be on the same line,
and it seems to be more picky when matching file (or really directory)
names with different numbers of trailing slashes.Signed-off-by: Jan Beulich
Acked-by: Sam Ravnborg
Andrew Benton
Cc:
Signed-off-by: Michal Marek
04 Dec, 2008
1 commit
-
With this fix a "make -s" is now really silent
Signed-off-by: Sam Ravnborg
29 Jan, 2008
1 commit
-
Rather than fixing the output directory in the generated Makefile,
determine it from the placement of Makefile. This allows moving
the build tree around or accessing it through different mount paths.(The lastword definition is a compatibility one for make prior to 3.81;
newer make will simply ignore it and use the [faster] built-in.)Signed-off-by: Jan Beulich
Signed-off-by: Sam Ravnborg
14 Dec, 2007
1 commit
-
The commit:
18c32dac75b187d1a4e858f3cfdf03e844129f5e "kbuild: fix
building with O=.. options"
disabled the creation of a Makefile in a new O=... directory. Restore it.Signed-off-by: Guillaume Chazarain
Signed-off-by: Sam Ravnborg
09 Dec, 2007
1 commit
-
The check introduced in commit:
4f1127e204377cbd2a56d112d323466f668e8334 "kbuild: fix
infinite make recursion"caused certain external modules not to build and
also caused 'make targz-pkg' to fail.
This is a minimal fix so we revert to previous
behaviour - but we do not overwrite the Makefile
in the top-level directory.Signed-off-by: Sam Ravnborg
Tested-by: Jay Cliburn
Cc: Jay Cliburn
13 Oct, 2007
1 commit
-
Change the invocations of make in the output directory Makefile and the
main Makefile for separate object trees to pass all goals to one $(MAKE)
via a new phony target "sub-make" and the existing target _all.When compiling with separate object directories, a separate make is called
in the context of another directory (from the output directory the main
Makefile is called, the Makefile is then restarted with current directory
set to the object tree). Before this patch, when multiple make command
goals are specified, each target results in a separate make invocation.
With make -j, these invocations may run in parallel, resulting in multiple
commands running in the same directory clobbering each others results.I did not try to address make -j for mixed dot-config and no-dot-config
targets. Because the order does matter, a solution was not obvious.
Perhaps a simple check for MAKEFLAGS having -j and refusing to run would
be appropriate.Signed-off-by: Milton Miller
Signed-off-by: Sam Ravnborg
08 May, 2006
1 commit
-
Change the conditional of the outputmakefile rule to be evaluated entirely
in make, and add a conditional to not touch the generated makefile when e.g.
running 'make install' as root while the build was done as non-root. Also
adjust the comment describing this, and move the message printing and
redirection to mkmakefile.Signed-off-by: Jan Beulich
Signed-off-by: Sam Ravnborg
19 Feb, 2006
1 commit
-
With the current way of generating the Makefile in the output directory
for builds outside of the source tree, specifying real targets (rather
than phony ones) doesn't work in an already (partially) built tree, as
the stub Makefile doesn't have any dependency information available.
Thus, all targets where files may actually exist must be listed
explicitly and, due to what I'd call a make misbehavior, directory
targets must then also be special cased.Signed-Off-By: Jan Beulich
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!