On 13 September 2013 11:45, Ingo Molnar <mi...@kernel.org> wrote: > > * Jean Pihet <jean.pi...@linaro.org> wrote: > >> Hi, >> >> On 13 September 2013 07:09, Ingo Molnar <mi...@kernel.org> wrote: >> > >> > * David Ahern <dsah...@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. Ok! I just sent a patch to feature-tests.mak for the newly added dwarf unwinding feature ('perf tools: Check libunwind for availability of dwarf parsing feature').
Thanks, Jean > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
