aboutsummaryrefslogtreecommitdiffstats
path: root/tools/build/Makefile.build (follow)
AgeCommit message (Collapse)AuthorFilesLines
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman1-0/+1
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 <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-06-06kbuild: simplify silent build (-s) detectionMasahiro Yamada1-7/+1
This allows to detect -s (--silent) option without checking GNU Make version. As commit e36aaea28972 ("kbuild: Fix silent builds with make-4") pointed out, GNU Make 4.x changed the way/order it presents the command line options into MAKEFLAGS. In Make 3.8x, 's' is always the first in a group of short options. The group may be prefixed with '-' in some cases. In Make 4.x, 's' is always the last in a group of short options. As commit e6ac89fabd03 ("kbuild: Correctly deal with make options which contain an 's'") addressed, we also need to deal with long options that contain 's', like --warn-undefined-variables. Test cases: [1] command line input: make --silent -> MAKEFLAGS for Make 3.8x: s -> MAKEFLAGS for Make 4.x : s [2] command line input: make -srR -> MAKEFLAGS for Make 3.8x: sRr -> MAKEFLAGS for Make 4.x : rRs [3] command line input: make -s -rR --warn-undefined-variables -> MAKEFLAGS for Make 3.8x: --warn-undefined-variables -sRr -> MAKEFLAGS for Make 4.x : rRs --warn-undefined-variables My idea to cater to all the cases more easily is to filter out long options (--%), then search 's' with $(findstring ...). This way will be more future-proof even if future versions of Make put 's' in the middle of the group. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-26tools build: Add tools tree support for 'make -s'Josh Poimboeuf1-0/+10
When doing a kernel build with 'make -s', everything is silenced except the objtool build. That's because the tools tree support for silent builds is some combination of missing and broken. Three changes are needed to fix it: - Makefile: propagate '-s' to the sub-make's MAKEFLAGS variable so the tools Makefiles can see it. - tools/scripts/Makefile.include: fix the tools Makefiles' ability to recognize '-s'. The MAKE_VERSION and MAKEFLAGS checks are copied from the top-level Makefile. This silences the "DESCEND objtool" message. - tools/build/Makefile.build: add support to the tools Build files for recognizing '-s'. Again the MAKE_VERSION and MAKEFLAGS checks are copied from the top-level Makefile. This silences all the object compile/link messages. Reported-and-Tested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Michal Marek <mmarek@suse.com> Link: http://lkml.kernel.org/r/e8967562ef640c3ae9a76da4ae0f4e47df737c34.1484799200.git.jpoimboe@redhat.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2016-10-05tools build: Support compiling C++ source fileWang Nan1-0/+7
Add new rule to compile .cpp file to .o use g++. C++ support is required for built-in clang and LLVM support. Linker side support will be introduced by following commits. Signed-off-by: Wang Nan <wangnan0@huawei.com> Cc: Alexei Starovoitov <ast@fb.com> Cc: He Kuang <hekuang@huawei.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Zefan Li <lizefan@huawei.com> Cc: pi3orama@163.com Link: http://lkml.kernel.org/r/1474874832-134786-2-git-send-email-wangnan0@huawei.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2016-10-03tools build: Add support for host programs formatJiri Olsa1-4/+15
In some cases, like for fixdep and shortly for jevents, we need to build a tool to run on the host that will be used in building a tool, such as perf, that is being cross compiled, so do like the kernel and provide HOSTCC, HOSTLD and HOSTAR to do that. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Requested-by: Andi Kleen <andi@firstfloor.org> Requested-and-Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Cc: linuxppc-dev@lists.ozlabs.org Link: http://lkml.kernel.org/r/20160927141846.GA6589@krava Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2016-04-20kbuild: rename cmd_cc_i_c to cmd_cpp_i_cMasahiro Yamada1-4/+4
This command just preprocesses .c files into .i files, so cmd_cpp_i_c seems more suitable. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-03-03tools build: Use .s extension for preprocessed assembler codeMasahiro Yamada1-1/+1
The "man gcc" says .i extension represents the file is C source code that should not be preprocessed. Here, .s should be used. For clarification, .c ---(preprocess)---> .i .S ---(preprocess)---> .s Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Aaro Koskinen <aaro.koskinen@nokia.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Lukas Wunner <lukas@wunner.de> Link: http://lkml.kernel.org/r/1454263140-19670-1-git-send-email-yamada.masahiro@socionext.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-09-28tools build: Make the fixdep helper part of the build processJiri Olsa1-0/+7
Making the fixdep helper to be invoked within dep-cmd. Each user of the build framework needs to make sure fixdep exists before executing the build itself. If the build doesn't find fixdep, it falls back to the old style dependency tracking. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Cc: David Ahern <dsahern@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1443004442-32660-6-git-send-email-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-08-26tools build: Allow duplicate objects in the object listJiri Olsa1-1/+1
It's sometimes useful to specify the object affiliation to multiple config options like: libperf-$(CONFIG_X86) += tsc.o libperf-$(CONFIG_AUXTRACE) += tsc.o while the object itself is linked only once. Adding the support for this and ignoring duplicate objects in the object list. Suggested-by: Arnaldo Carvalho de Melo <acme@kernel.org> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/20150826130103.GF22670@krava.redhat.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-08-17perf tools: Add Intel PT instruction decoderAdrian Hunter1-0/+2
Add support for decoding instructions for Intel Processor Trace. The kernel x86 instruction decoder is copied for this. This essentially provides intel_pt_get_insn() which takes a binary buffer, uses the kernel's x86 instruction decoder to get details of the instruction and then categorizes it for consumption by an Intel PT decoder. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/1439450095-30122-1-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-07-01perf tools: Create config.detected into OUTPUT directoryAaro Koskinen1-1/+1
Create config.detected into OUTPUT directory instead of source directory. This fixes parallel builds that share the same source directory. Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1435751683-18500-1-git-send-email-aaro.koskinen@nokia.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-06-22Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds1-4/+4
Pull perf fixes from Ingo Molnar: "These are the left over fixes from the v4.1 cycle" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf tools: Fix build breakage if prefix= is specified perf/x86: Honor the architectural performance monitoring version perf/x86/intel: Fix PMI handling for Intel PT perf/x86/intel/bts: Fix DS area sharing with x86_pmu events perf/x86: Add more Broadwell model numbers perf: Fix ring_buffer_attach() RCU sync, again
2015-06-19perf tools: Fix build breakage if prefix= is specifiedLukas Wunner1-4/+4
Invoking Makefile.perf with prefix= breaks the build since Makefile.perf hands that variable down to Makefile.build where it overrides prefix := $(subst ./,,$(OUTPUT)$(dir)/) leading to errors like this: No rule to make target '/usrabspath.o', needed by '/usrlibperf-in.o' Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: David Ahern <dsahern@gmail.com> Fixes: c819e2cf2eb6f65d3208d195d7a0edef6108d5 Link: http://lkml.kernel.org/r/5582c48a.84a22b0a.a918.5285SMTPIN_ADDED_MISSING@mx.google.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-05-29perf build: Do not fail on missing Build fileJiri Olsa1-1/+1
Allow nesting into directories without Build file. Currently we force include of the Build file, which fails the build when the Build file is missing. We already support empty *-in.o' objects if there's nothing in the directory to be compiled, so we can just use it for missing Build file cases. Also adding this case under tests. Reported-by: Rabin Vincent <rabin.vincent@axis.com> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Cc: David Ahern <dsahern@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Rabin Vincent <rabin.vincent@axis.com> Link: http://lkml.kernel.org/r/1432914178-24086-1-git-send-email-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-02-12perf build: Display make commands on V=1Jiri Olsa1-1/+3
Get more verbose output wrt displaying executed commands from make. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Tested-by: Will Deacon <will.deacon@arm.com> Cc: Alexis Berlemont <alexis.berlemont@gmail.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-68v67h59zoz7ilb1ggcuff3j@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-02-12perf build: Add single target build framework supportJiri Olsa1-1/+19
Add support to build single targets, like: $ make util/map.o # objects $ make util/map.i # preprocessor $ make util/map.s # assembly Signed-off-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Tested-by: Will Deacon <will.deacon@arm.com> Cc: Alexis Berlemont <alexis.berlemont@gmail.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-tt10y0dmweq6rjaod937rpb4@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-02-12perf build: Add libperf objects buildingJiri Olsa1-0/+3
Move the util objects building under build framework. Add the new libperf build object so it's separated from the rest of the perf code and could be librarized. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Tested-by: Will Deacon <will.deacon@arm.com> Cc: Alexis Berlemont <alexis.berlemont@gmail.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-574tgt9t23tnxo9td8qjiibc@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-02-12tools build: Add subdir supportJiri Olsa1-0/+7
Add support to make directory any time we build objects out of the tree (O=/tmp/krava) and the output directory does not exist. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Tested-by: Will Deacon <will.deacon@arm.com> Cc: Alexis Berlemont <alexis.berlemont@gmail.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-h80ukls4o2kpr0e4c4bfln6u@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-02-12tools build: Add detected config supportJiri Olsa1-0/+3
Adding support to include detected configuration makefile into the build process. This will allow the Build objects to be configurable based on the config data, like: perf-$(CONFIG_KRAVA) += krava.o The configuration is stored in '.config-detected' file, which is generated for each compilation. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Tested-by: Will Deacon <will.deacon@arm.com> Cc: Alexis Berlemont <alexis.berlemont@gmail.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-bl8qho0ubck7aqrbbfu9inlm@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-02-11tools build: Add new build supportJiri Olsa1-0/+97
Adding new build framework into 'tools/build' to be used by tools. There's no change for actual building at this point, it comes in the next patches. The idea and more details are explained in the 'tools/build/Documentation/Build.txt' file. I adopted everything from the kernel build system, with some changes to allow for multiple binaries build definitions. While the kernel's build output is single image (forget modules) we need to be able to build several binaries/libraries. The basic idea is that sser provides 'Build' files with objects definitions like: perf-y += a.o perf-y += b.o libperf-y += c.o libperf-y += d.o and the build framework outputs files: perf-in.o # a.o, b.o compiled in libperf-in.o # c.o, d.o compiled in Signed-off-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Tested-by: Will Deacon <will.deacon@arm.com> Cc: Alexis Berlemont <alexis.berlemont@gmail.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-fbj22h4av0otlxupwcmrxgpa@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>