Re: [PATCH 01/15] perf build: Disable default check for libbabeltrace

[Arnaldo Carvalho de Melo <acme@redhat.com>]

Em Fri, Mar 13, 2015 at 05:20:11PM +0100, Jiri Olsa escreveu:
> On Fri, Mar 13, 2015 at 12:36:21PM -0300, Arnaldo Carvalho de Melo wrote:
> 
> SNIP
> 
> > 
> > Auto-detecting system features:
> > ...                         dwarf: [ on  ]
> > ...                         glibc: [ on  ]
> > ...                          gtk2: [ on  ]
> > ...                      libaudit: [ on  ]
> > ...                        libbfd: [ on  ]
> > ...                        libelf: [ on  ]
> > ...                       libnuma: [ on  ]
> > ...                       libperl: [ on  ]
> > ...                     libpython: [ on  ]
> > ...                      libslang: [ on  ]
> > ...                     libunwind: [ OFF ]
> > ...            libdw-dwarf-unwind: [ on  ]
> > ...                          zlib: [ on  ]
> > ...     DWARF post unwind library: libdw
> > 
> >   GEN      common-cmds.h
> > 
> > It continues trying to find babeltrace, does not find it, emits the warning and
> > just doesn't show the OFF message :-\
> > 
> > Can you explain _why_ this is needed?  I.e. is it to speed up feature checking?
> > In what way, etc. For casual readers the intent of this patch may be difficult
> > to grasp, no?
> > 
> > What am I missing?
> 
> this patch removes babeltrace from:
>   - detected features display  -> so user's not curious where to get the latest babeltrace version ;-)
>   - test-all optimization      -> so we could use features build speed up, missing babeltrace was stoping this
> 
> but we still check for babeltrace (out of the default list code)
> in order to enable the ctf convert code if it's in the system
> 
> I admit the extra warning about missing babeltrace support
> might be confusing, I can remove it.. ;-)
> 
> I think we could add new class of features that are enabled
> just on demand and not checked by default at all, like:
>   'make BABELTRACE=1' or via .config,
> but we need to add support for that first

Thanks for explaining, that covers one of my peeves, i.e. the cset
comment wasn't clear, now it is a bit better, thanks!

The other is for someone not interested in how the feature detection
works but then sees a warning about a feature not being available but
that feature doesn't appear on the followup summary of features that are
ON or OFF the build...

So I think that when we think that some feature is experimental, for any
reason, for instance, because it is based on some feature that is not on
a released version of the library one needs to link against, to only
bother with trying to check if it is available and link against it if so
if it is _explicitely_ asked for.

I.e. documentation should state that perf can have support for that
feature, but only if the user does:

1. installs the precisely described version that has what is needed.

2. Explicitely asks, in the make command line, for that feature.

In the case at hand that would not even be a library release, but a
specific git commit on babeltrace's repo.

That would be a speedup! ;-)

- Arnaldo

P.S. After all, we're not short on features, look at the ldd output...
Ok, I need to keep on merging the .config stuff, but even then, I guess
we need to have more of a dlopen approach to all those features, so that
one can install a package without dragging hell and its kitchen sink.