perf tools: Makefile: PYTHON{,_CONFIG} to bandage Python 3 incompatibility
Currently, Python 3 is not supported by perf's code; this
can cause the build to fail for systems that have Python 3
installed as the default python:
python{,-config}
The Correct Solution is to write compatibility code so that
Python 3 works out-of-the-box.
However, users often have an ancillary Python 2 installed:
python2{,-config}
Therefore, a quick fix is to allow the user to specify those
ancillary paths as the python binaries that Makefile should
use, thereby avoiding Python 3 altogether; as an added benefit,
the Python binaries may be installed in non-standard locations
without the need for updating any PATH variable.
This commit adds the ability to set PYTHON and/or PYTHON_CONFIG
either as environment variables or as make variables on the
command line; the paths may be relative, and usually only PYTHON
is necessary in order for PYTHON_CONFIG to be defined implicitly.
Some rudimentary error checking is performed when the user
explicitly specifies a value for any of these variables.
In addition, this commit introduces significantly robust makefile
infrastructure for working with paths and communicating with the
shell; it's currently only used for handling Python, but I hope
it will prove useful in refactoring the makefiles.
Thanks to:
Raghavendra D Prabhu <rprabhu@wnohang.net>
for motivating this patch.
Acked-by: Raghavendra D Prabhu <rprabhu@wnohang.net>
Link: http://lkml.kernel.org/r/e987828e-87ec-4973-95e7-47f10f5d9bab-mfwitten@gmail.com
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-04-03 01:46:09 +04:00
# This allows us to work with the newline character:
d e f i n e n e w l i n e
e n d e f
newline := $( newline)
# nl-escape
#
# Usage: escape = $(call nl-escape[,escape])
#
# This is used as the common way to specify
# what should replace a newline when escaping
# newlines; the default is a bizarre string.
#
2013-01-09 01:22:36 +04:00
nl-escape = $( if $( 1) ,$( 1) ,m822df3020w6a44id34bt574ctac44eb9f4n)
perf tools: Makefile: PYTHON{,_CONFIG} to bandage Python 3 incompatibility
Currently, Python 3 is not supported by perf's code; this
can cause the build to fail for systems that have Python 3
installed as the default python:
python{,-config}
The Correct Solution is to write compatibility code so that
Python 3 works out-of-the-box.
However, users often have an ancillary Python 2 installed:
python2{,-config}
Therefore, a quick fix is to allow the user to specify those
ancillary paths as the python binaries that Makefile should
use, thereby avoiding Python 3 altogether; as an added benefit,
the Python binaries may be installed in non-standard locations
without the need for updating any PATH variable.
This commit adds the ability to set PYTHON and/or PYTHON_CONFIG
either as environment variables or as make variables on the
command line; the paths may be relative, and usually only PYTHON
is necessary in order for PYTHON_CONFIG to be defined implicitly.
Some rudimentary error checking is performed when the user
explicitly specifies a value for any of these variables.
In addition, this commit introduces significantly robust makefile
infrastructure for working with paths and communicating with the
shell; it's currently only used for handling Python, but I hope
it will prove useful in refactoring the makefiles.
Thanks to:
Raghavendra D Prabhu <rprabhu@wnohang.net>
for motivating this patch.
Acked-by: Raghavendra D Prabhu <rprabhu@wnohang.net>
Link: http://lkml.kernel.org/r/e987828e-87ec-4973-95e7-47f10f5d9bab-mfwitten@gmail.com
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-04-03 01:46:09 +04:00
# escape-nl
#
# Usage: escaped-text = $(call escape-nl,text[,escape])
#
# GNU make's $(shell ...) function converts to a
# single space each newline character in the output
# produced during the expansion; this may not be
# desirable.
#
# The only solution is to change each newline into
# something that won't be converted, so that the
# information can be recovered later with
# $(call unescape-nl...)
#
escape-nl = $( subst $( newline) ,$( call nl-escape,$( 2) ) ,$( 1) )
# unescape-nl
#
# Usage: text = $(call unescape-nl,escaped-text[,escape])
#
# See escape-nl.
#
unescape-nl = $( subst $( call nl-escape,$( 2) ) ,$( newline) ,$( 1) )
# shell-escape-nl
#
# Usage: $(shell some-command | $(call shell-escape-nl[,escape]))
#
# Use this to escape newlines from within a shell call;
# the default escape is a bizarre string.
#
# NOTE: The escape is used directly as a string constant
# in an `awk' program that is delimited by shell
# single-quotes, so be wary of the characters
# that are chosen.
#
d e f i n e s h e l l - e s c a p e - n l
a w k 'NR==1 {t=$$0} NR>1 {t=t "$(nl-escape)" $$0} END {printf t}'
e n d e f
# shell-unescape-nl
#
# Usage: $(shell some-command | $(call shell-unescape-nl[,escape]))
#
# Use this to unescape newlines from within a shell call;
# the default escape is a bizarre string.
#
# NOTE: The escape is used directly as an extended regular
# expression constant in an `awk' program that is
# delimited by shell single-quotes, so be wary
# of the characters that are chosen.
#
# (The bash shell has a bug where `{gsub(...),...}' is
# misinterpreted as a brace expansion; this can be
# overcome by putting a space between `{' and `gsub').
#
d e f i n e s h e l l - u n e s c a p e - n l
a w k 'NR==1 {t=$$0} NR>1 {t=t "\n" $$0} END { gsub(/$(nl-escape)/,"\n",t); printf t }'
e n d e f
# escape-for-shell-sq
#
# Usage: embeddable-text = $(call escape-for-shell-sq,text)
#
# This function produces text that is suitable for
# embedding in a shell string that is delimited by
# single-quotes.
#
escape-for-shell-sq = $( subst ',' \' ' ,$( 1) )
# shell-sq
#
# Usage: single-quoted-and-escaped-text = $(call shell-sq,text)
#
shell-sq = '$(escape-for-shell-sq)'
# shell-wordify
#
# Usage: wordified-text = $(call shell-wordify,text)
#
# For instance:
#
# |define text
# |hello
# |world
# |endef
# |
# |target:
# | echo $(call shell-wordify,$(text))
#
# At least GNU make gets confused by expanding a newline
# within the context of a command line of a makefile rule
# (this is in constrast to a `$(shell ...)' function call,
# which can handle it just fine).
#
# This function avoids the problem by producing a string
# that works as a shell word, regardless of whether or
# not it contains a newline.
#
# If the text to be wordified contains a newline, then
# an intrictate shell command substitution is constructed
# to render the text as a single line; when the shell
# processes the resulting escaped text, it transforms
# it into the original unescaped text.
#
# If the text does not contain a newline, then this function
# produces the same results as the `$(shell-sq)' function.
#
shell-wordify = $( if $( findstring $( newline) ,$( 1) ) ,$( _sw-esc-nl) ,$( shell-sq) )
d e f i n e _ s w - e s c - n l
"$$(echo $(call escape-nl,$(shell-sq),$(2)) | $(call shell-unescape-nl,$(2)))"
e n d e f
# is-absolute
#
# Usage: bool-value = $(call is-absolute,path)
#
2014-08-25 23:36:32 +04:00
is-absolute = $( shell echo $( shell-sq) | grep -q ^/ && echo y)
perf tools: Makefile: PYTHON{,_CONFIG} to bandage Python 3 incompatibility
Currently, Python 3 is not supported by perf's code; this
can cause the build to fail for systems that have Python 3
installed as the default python:
python{,-config}
The Correct Solution is to write compatibility code so that
Python 3 works out-of-the-box.
However, users often have an ancillary Python 2 installed:
python2{,-config}
Therefore, a quick fix is to allow the user to specify those
ancillary paths as the python binaries that Makefile should
use, thereby avoiding Python 3 altogether; as an added benefit,
the Python binaries may be installed in non-standard locations
without the need for updating any PATH variable.
This commit adds the ability to set PYTHON and/or PYTHON_CONFIG
either as environment variables or as make variables on the
command line; the paths may be relative, and usually only PYTHON
is necessary in order for PYTHON_CONFIG to be defined implicitly.
Some rudimentary error checking is performed when the user
explicitly specifies a value for any of these variables.
In addition, this commit introduces significantly robust makefile
infrastructure for working with paths and communicating with the
shell; it's currently only used for handling Python, but I hope
it will prove useful in refactoring the makefiles.
Thanks to:
Raghavendra D Prabhu <rprabhu@wnohang.net>
for motivating this patch.
Acked-by: Raghavendra D Prabhu <rprabhu@wnohang.net>
Link: http://lkml.kernel.org/r/e987828e-87ec-4973-95e7-47f10f5d9bab-mfwitten@gmail.com
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-04-03 01:46:09 +04:00
# lookup
#
# Usage: absolute-executable-path-or-empty = $(call lookup,path)
#
# (It's necessary to use `sh -c' because GNU make messes up by
# trying too hard and getting things wrong).
#
lookup = $( call unescape-nl,$( shell sh -c $( _l-sh) ) )
_l-sh = $( call shell-sq,command -v $( shell-sq) | $( call shell-escape-nl,) )
# is-executable
#
# Usage: bool-value = $(call is-executable,path)
#
# (It's necessary to use `sh -c' because GNU make messes up by
# trying too hard and getting things wrong).
#
is-executable = $( call _is-executable-helper,$( shell-sq) )
_is-executable-helper = $( shell sh -c $( _is-executable-sh) )
_is-executable-sh = $( call shell-sq,test -f $( 1) -a -x $( 1) && echo y)
# get-executable
#
# Usage: absolute-executable-path-or-empty = $(call get-executable,path)
#
# The goal is to get an absolute path for an executable;
# the `command -v' is defined by POSIX, but it's not
# necessarily very portable, so it's only used if
# relative path resolution is requested, as determined
# by the presence of a leading `/'.
#
get-executable = $( if $( 1) ,$( if $( is-absolute) ,$( _ge-abspath) ,$( lookup) ) )
_ge-abspath = $( if $( is-executable) ,$( 1) )
# get-supplied-or-default-executable
#
# Usage: absolute-executable-path-or-empty = $(call get-executable-or-default,variable,default)
#
d e f i n e g e t - e x e c u t a b l e - o r - d e f a u l t
perf tools: Revert regression in configuration of Python support
Among other things, the following:
commit 31160d7feab786c991780d7f0ce2755a469e0e5e
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: Pekka Enberg <penberg@kernel.org>
Link: http://lkml.kernel.org/r/CAOJsxLHv17Ys3M7P5q25imkUxQW6LE_vABxh1N3Tt7Mv6Ho4iw@mail.gmail.com
Signed-off-by: Michael Witten <mfwitten@gmail.com>
2013-04-17 06:23:16 +04:00
$( if $ ( $ ( 1) ) ,$ ( call _ge_attempt ,$ ( $ ( 1) ) ,$ ( 1) ) ,$ ( call _ge_attempt ,$ ( 2) ) )
perf tools: Makefile: PYTHON{,_CONFIG} to bandage Python 3 incompatibility
Currently, Python 3 is not supported by perf's code; this
can cause the build to fail for systems that have Python 3
installed as the default python:
python{,-config}
The Correct Solution is to write compatibility code so that
Python 3 works out-of-the-box.
However, users often have an ancillary Python 2 installed:
python2{,-config}
Therefore, a quick fix is to allow the user to specify those
ancillary paths as the python binaries that Makefile should
use, thereby avoiding Python 3 altogether; as an added benefit,
the Python binaries may be installed in non-standard locations
without the need for updating any PATH variable.
This commit adds the ability to set PYTHON and/or PYTHON_CONFIG
either as environment variables or as make variables on the
command line; the paths may be relative, and usually only PYTHON
is necessary in order for PYTHON_CONFIG to be defined implicitly.
Some rudimentary error checking is performed when the user
explicitly specifies a value for any of these variables.
In addition, this commit introduces significantly robust makefile
infrastructure for working with paths and communicating with the
shell; it's currently only used for handling Python, but I hope
it will prove useful in refactoring the makefiles.
Thanks to:
Raghavendra D Prabhu <rprabhu@wnohang.net>
for motivating this patch.
Acked-by: Raghavendra D Prabhu <rprabhu@wnohang.net>
Link: http://lkml.kernel.org/r/e987828e-87ec-4973-95e7-47f10f5d9bab-mfwitten@gmail.com
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-04-03 01:46:09 +04:00
e n d e f
2015-02-28 11:17:50 +03:00
_ge_attempt = $( if $( get-executable) ,$( get-executable) ,$( call _gea_err,$( 2) ) )
perf tools: Makefile: PYTHON{,_CONFIG} to bandage Python 3 incompatibility
Currently, Python 3 is not supported by perf's code; this
can cause the build to fail for systems that have Python 3
installed as the default python:
python{,-config}
The Correct Solution is to write compatibility code so that
Python 3 works out-of-the-box.
However, users often have an ancillary Python 2 installed:
python2{,-config}
Therefore, a quick fix is to allow the user to specify those
ancillary paths as the python binaries that Makefile should
use, thereby avoiding Python 3 altogether; as an added benefit,
the Python binaries may be installed in non-standard locations
without the need for updating any PATH variable.
This commit adds the ability to set PYTHON and/or PYTHON_CONFIG
either as environment variables or as make variables on the
command line; the paths may be relative, and usually only PYTHON
is necessary in order for PYTHON_CONFIG to be defined implicitly.
Some rudimentary error checking is performed when the user
explicitly specifies a value for any of these variables.
In addition, this commit introduces significantly robust makefile
infrastructure for working with paths and communicating with the
shell; it's currently only used for handling Python, but I hope
it will prove useful in refactoring the makefiles.
Thanks to:
Raghavendra D Prabhu <rprabhu@wnohang.net>
for motivating this patch.
Acked-by: Raghavendra D Prabhu <rprabhu@wnohang.net>
Link: http://lkml.kernel.org/r/e987828e-87ec-4973-95e7-47f10f5d9bab-mfwitten@gmail.com
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2011-04-03 01:46:09 +04:00
_gea_err = $( if $( 1) ,$( error Please set '$(1)' appropriately) )