[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180109092646.GB11520@krava>
Date: Tue, 9 Jan 2018 10:26:46 +0100
From: Jiri Olsa <jolsa@...hat.com>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Jiri Olsa <jolsa@...nel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
lkml <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
David Ahern <dsahern@...il.com>,
Andi Kleen <ak@...ux.intel.com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Subject: [PATCH] perf build: Display EXTRA features for VF=1 build
On Mon, Jan 08, 2018 at 06:16:49PM +0100, Jiri Olsa wrote:
> On Mon, Jan 08, 2018 at 06:11:22PM +0100, Jiri Olsa wrote:
> > On Mon, Jan 08, 2018 at 12:24:33PM -0300, Arnaldo Carvalho de Melo wrote:
> >
> > SNIP
> >
> > >
> > > Works:
> > >
> > > [acme@...et perf]$ ldd ~/bin/perf | grep babel
> > > libbabeltrace-ctf.so.1 => /lib64/libbabeltrace-ctf.so.1 (0x00007fcb688d0000)
> > > libbabeltrace.so.1 => /lib64/libbabeltrace.so.1 (0x00007fcb67e92000)
> > > [acme@...et perf]$ rpm -q libbabeltrace-devel
> > > libbabeltrace-devel-1.5.3-1.fc27.x86_64
> > > [acme@...et perf]$
> > >
> > > But then, if we show:
> > >
> > > Auto-detecting system features:
> > > ... dwarf: [ on ]
> > > ... dwarf_getlocations: [ on ]
> > > ... glibc: [ on ]
> > > ... gtk2: [ on ]
> > > ... libaudit: [ on ]
> > > ... libbfd: [ on ]
> > > ... libelf: [ on ]
> > > ... libnuma: [ on ]
> > > ... numa_num_possible_cpus: [ on ]
> > > ... libperl: [ on ]
> > > ... libpython: [ on ]
> > > ... libslang: [ on ]
> > > ... libcrypto: [ on ]
> > > ... libunwind: [ on ]
> > > ... libdw-dwarf-unwind: [ on ]
> > > ... zlib: [ on ]
> > > ... lzma: [ on ]
> > > ... get_cpuid: [ on ]
> > > ... bpf: [ on ]
> > >
> > > Shoudln't we tell the user that babeltrace was linked too?
> >
> > the logic is just to simply display the state of features
> > which we provide in FEATURE_DISPLAY variable, which is
> > believed to be common and important enough to display
> > status about
> >
> > maybe we could display it with 'make VF=1' output?
>
> like in patch attached ;-)
with changelog
thanks,
jirka
---
Display state of the rest of the features (FEATURE_TESTS_EXTRA)
for 'make VF=1' build. These features are detected manually by
perf's Makefile.config so they can't be displayed with the
main list, but only after we're done in Makefile.config.
$ make VF=1
BUILD: Doing 'make -j4' parallel build
Auto-detecting system features:
... dwarf: [ on ]
... dwarf_getlocations: [ on ]
... glibc: [ on ]
... gtk2: [ on ]
SNIP
... timerfd: [ on ]
... sched_getcpu: [ on ]
... sdt: [ on ]
... setns: [ on ]
extra features:
... bionic: [ OFF ]
... compile-32: [ on ]
... compile-x32: [ OFF ]
... cplus-demangle: [ on ]
... hello: [ OFF ]
... libbabeltrace: [ on ]
... liberty: [ on ]
... liberty-z: [ on ]
... libunwind-debug-frame: [ OFF ]
... libunwind-debug-frame-arm: [ OFF ]
... libunwind-debug-frame-aarch64: [ OFF ]
SNIP
Link: http://lkml.kernel.org/n/tip-q4r73p2c6wfag2s38fpsim8v@git.kernel.org
Signed-off-by: Jiri Olsa <jolsa@...nel.org>
---
tools/perf/Makefile.config | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 12dec6ea5ed2..92265b32dddd 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -947,6 +947,10 @@ define print_var_code
endef
ifeq ($(VF),1)
+ # Display EXTRA features which are detected manualy
+ # from here with feature_check call and thus cannot
+ # be partof global state output.
+ $(foreach feat,$(FEATURE_TESTS_EXTRA),$(call feature_print_status,$(feat),))
$(call print_var,prefix)
$(call print_var,bindir)
$(call print_var,libdir)
--
2.13.6
Powered by blists - more mailing lists