From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753776AbcCAMzf (ORCPT ); Tue, 1 Mar 2016 07:55:35 -0500 Received: from mail.kernel.org ([198.145.29.136]:52705 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752688AbcCAMzd (ORCPT ); Tue, 1 Mar 2016 07:55:33 -0500 Date: Tue, 1 Mar 2016 09:55:28 -0300 From: Arnaldo Carvalho de Melo To: Jiri Olsa Cc: Jiri Olsa , Wang Nan , Linux Kernel Mailing List Subject: Re: libbabeltrace feature detection message Message-ID: <20160301125528.GB3170@kernel.org> References: <20160229150720.GC32719@kernel.org> <20160301125124.GA26168@krava.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160301125124.GA26168@krava.redhat.com> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Tue, Mar 01, 2016 at 01:51:24PM +0100, Jiri Olsa escreveu: > On Mon, Feb 29, 2016 at 12:07:20PM -0300, Arnaldo Carvalho de Melo wrote: > > > > Hi Jiri, > > > > While testing a patch by Wang, that requires building with > > libbabeltrace, I noticed that there are no feature detection message > > telling that it was found successfully. The end result is the desired > > one, it builds with babeltrace, but I wonder if we couldn't have the > > [ok] line for it: > > well, we removed it, because the latest version if libbabeltrace pkg And we should keep it like that, I'm talking about something else. > perf needs wasn't present in common distros.. so for most users that > would print 'OFF' as a status.. that might have changed now, dont know > > anyway, for libbabeltrace and other in FEATURE_TESTS_EXTRA it's not possible > to print their status easily at the moment, because the status isn't known at > the time tools/build/Makefile.feature is included in config/Makefile Ok, I guess this should then be the problem to solve, when possible, i.e. what I am talking about is: 1. It should remain as is while the generally available babeltrace library doesn't have what we need. 2. But, if we explicitely ask for it to be built, then it should do the feature detection as usual, checking if what we asked it to do, to enable building with libbabeltrace, is possible, if so, print: babeltrace [ok] :-) > I'll check if we can reorg the code a little to get the full status at the end Thanks! > jirka > > > > > > > [acme@jouet linux]$ rm -rf /tmp/build/perf ; mkdir -p /tmp/build/perf ; make LIBBABELTRACE=1 O=/tmp/build/perf -C tools/perf install-bin > > make: Entering directory '/home/acme/git/linux/tools/perf' > > BUILD: Doing 'make -j4' parallel build > > > > Auto-detecting system features: > > ... dwarf: [ 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 ] > > > > GEN /tmp/build/perf/common-cmds.h > > CC /tmp/build/perf/fixdep.o > > LD /tmp/build/perf/fixdep-in.o > > > > [acme@jouet linux]$ ldd ~/bin/perf | grep babel > > libbabeltrace-ctf.so.1 => /lib64/libbabeltrace-ctf.so.1 (0x00007fce5c405000) > > libbabeltrace.so.1 => /lib64/libbabeltrace.so.1 (0x00007fce5bd69000) > > [acme@jouet linux]$ > > > > > > - Arnaldo