1. 18 Mar, 2016 1 commit
  2. 10 Dec, 2015 1 commit
  3. 27 May, 2015 1 commit
  4. 02 Mar, 2015 1 commit
    • Ingo Molnar's avatar
      perf tools: Remove annoying extra message from the features build · a6a76ba9
      Ingo Molnar authored
      This message:
      
        Makefile:153: The path 'python-config' is not executable.
      
      Appears on every perf build that does not have a sufficient python
      environment installed. It's really just an internal detail of python
      configuration pass and users should not see it - and it's pretty
      meaningless to them in any case because the message is not very helpful.
      (So it's not executable. Why does that matter? What can the user do
      about it?)
      
      Remove the warning, the missing python feature warning is sufficient:
      
        config/Makefile:566: No python-config tool was found
        config/Makefile:566: Python support will not be built
      
      although even that one isn't very helpful to users: so no Python support
      will be built, what can the user do to fix that? Most other such
      warnings give package install suggestions.
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: David Ahern <david.ahern@oracle.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20150228081750.GA31887@gmail.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      a6a76ba9
  5. 17 Sep, 2014 1 commit
  6. 19 Dec, 2013 1 commit
  7. 11 Oct, 2013 2 commits
  8. 09 Oct, 2013 1 commit
  9. 09 Jul, 2013 1 commit
    • Michael Witten's avatar
      perf tools: Revert regression in configuration of Python support · a363a9da
      Michael Witten authored
      Among other things, the following:
      
        commit 31160d7f
        Date:   Tue Jan 8 16:22:36 2013 -0500
        perf tools: Fix GNU make v3.80 compatibility issue
      
      attempts to aid the user by tapping into an existing error message,
      as described in the commit message:
      
        ... Also fix an issue where _get_attempt was called with only
        one argument. This prevented the error message from printing
        the name of the variable that can be used to fix the problem.
      
      or more precisely:
      
        -$(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2)))
        +$(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2),$(1)))
      
      However, The "missing" argument was in fact missing on purpose; it's
      absence is a signal that the error message should be skipped, because
      the failure would be due to the default value, not any user-supplied
      value.  This can be seen in how `_ge_attempt' uses `gea_err' (in the
      config/utilities.mak file):
      
        _ge_attempt = $(if $(get-executable),$(get-executable),$(_gea_warn)$(call _gea_err,$(2)))
        _gea_warn = $(warning The path '$(1)' is not executable.)
        _gea_err  = $(if $(1),$(error Please set '$(1)' appropriately))
      
      That is, because the argument is no longer missing, the value `$(1)'
      (associated with `_gea_err') always evaluates to true, thus always
      triggering the error condition that is meant to be reserved for
      only the case when a user explicitly supplies an invalid value.
      
      Concretely, the result is a regression in the Makefile's configuration
      of python support; rather than gracefully disable support when the
      relevant executables cannot be found according to default values, the
      build process halts in error as though the user explicitly supplied
      the values.
      
      This new commit simply reverts the offending one-line change.
      Reported-by: default avatarPekka Enberg <penberg@kernel.org>
      Link: http://lkml.kernel.org/r/CAOJsxLHv17Ys3M7P5q25imkUxQW6LE_vABxh1N3Tt7Mv6Ho4iw@mail.gmail.comSigned-off-by: default avatarMichael Witten <mfwitten@gmail.com>
      a363a9da
  10. 08 Jul, 2013 1 commit
  11. 24 Jan, 2013 1 commit
  12. 26 Oct, 2012 1 commit
  13. 24 Oct, 2012 1 commit
  14. 19 Apr, 2011 2 commits