Re: [GIT PULL] perf fixes

[Ingo Molnar <mingo@kernel.org>]

* Jean Pihet <jean.pihet@linaro.org> wrote:

> Hi,
> 
> On 13 September 2013 07:09, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * David Ahern <dsahern@gmail.com> wrote:
> >
> >> > By default a simple 'make' should build perf to the maximum extent
> >> > possible, with no other input required from the user - with warnings
> >> > displayed as package install suggestions.
> >>
> >> By default there is no config. Autoprobing generates a first one or a
> >> user can specify a defconfig.
> >
> > This could work if there's not two but three states for individual
> > features:
> >
> >   - autoprobe
> >   - on
> >   - off
> >
> > and if autoprobe, if a system feature has been probed successfully,
> > automatically turned 'autoprobe' entries into 'on'.
> >
> > That would give us the best of all worlds - autodetection, configurability
> > and caching:
> >
> >  - initial user types 'make' and gets a .config that has almost all
> >    entries 'on', a few 'autoprobe'.
> >
> >  - once the user installs a dependency, the corresponding .config entry
> >    turns into 'on'.
> >
> >  - the regular user or developers would have libraries that turn all
> >    entries in the .config to 'on'.
> >
> >  - if a user is genuinely uninterested in a feature, he can mark it 'off',
> >    which would then stay off permanently. This could also be used by
> >    embedded/specialized builds.
> >
> >  - other specialized users, like distro builds, could use a .config with
> >    all entries 'on' and could enforce the presence of all dependencies for
> >    a successful build. [We could add 'make allyesconfig' to help that.]
> 
> Is there a way to detect the presence of a dependency and _also_ check 
> its version? Some new features are depending on a recent version of a 
> library, e.g. dwarf unwinding depends on libunwind >= 1.1 (cf. 
> http://www.spinics.net/lists/kernel/msg1598951.html).

Yeah, see the testcases in tools/perf/config/feature-tests.mak, they 
typically include the latest library API usages, which will fail on older 
versions.

That kind of 'does it actually work?' test is a lot more robust than 
explicit version checks, and combined with caching it should be fast and 
parallelizable as well. (One of the problems of the current simple 
implementation of the feature tests is that they are 20 serial tests with 
no parallelization.)

Thanks,

	Ingo