* [PATCH] build/data: Don't expand python functions before execution [API change]
@ 2016-02-02 14:07 Richard Purdie
2016-02-02 14:41 ` [Openembedded-architecture] " Burton, Ross
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Richard Purdie @ 2016-02-02 14:07 UTC (permalink / raw)
To: bitbake-devel; +Cc: openembedded-architecture
Right now, if you have some python code like:
X = "a"
def somefunction(d):
d.setVar("X", "b")
d.setVar("Y", "${X}")
then any sane person would expect that Y = "b" at the end of the
function. This is not the case, Y = "a".
This is due to the python function being expanded before execution, the
executed code would read d.setVar("Y", "a"). This understandably
confuses people, it also makes it near impossible to write ${} in a
python function without unintended things happening.
I think there is general agreement we should fix this and standardise
on non-expansion of python functions. We already don't expand anonymous
python (mostly).
I've checked OE-Core with buildhistory before and after this change and
there were a small number of issues this exposed which I've sent
patches for.
I propose we default to not expanding python code and then deal with
any consequences from that if/as/where identified. This will improve
new user understanding and usability of the system, it also allows
several long standing weird expansion issues to be fixed.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
diff --git a/bitbake/lib/bb/build.py b/bitbake/lib/bb/build.py
index 52a4916..b7c49eb 100644
--- a/bitbake/lib/bb/build.py
+++ b/bitbake/lib/bb/build.py
@@ -239,7 +239,7 @@ def exec_func_python(func, d, runfile, cwd=None):
"""Execute a python BB 'function'"""
bbfile = d.getVar('FILE', True)
- code = _functionfmt.format(function=func, body=d.getVar(func, True))
+ code = _functionfmt.format(function=func, body=d.getVar(func, False))
bb.utils.mkdirhier(os.path.dirname(runfile))
with open(runfile, 'w') as script:
bb.data.emit_func_python(func, script, d)
diff --git a/bitbake/lib/bb/data.py b/bitbake/lib/bb/data.py
index 1f1f0d2..86ad4ed 100644
--- a/bitbake/lib/bb/data.py
+++ b/bitbake/lib/bb/data.py
@@ -308,7 +308,7 @@ def emit_func_python(func, o=sys.__stdout__, d = init()):
write_func(func, o, True)
pp = bb.codeparser.PythonParser(func, logger)
- pp.parse_python(d.getVar(func, True))
+ pp.parse_python(d.getVar(func, False))
newdeps = pp.execs
newdeps |= set((d.getVarFlag(func, "vardeps", True) or "").split())
seen = set()
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [Openembedded-architecture] [PATCH] build/data: Don't expand python functions before execution [API change]
2016-02-02 14:07 [PATCH] build/data: Don't expand python functions before execution [API change] Richard Purdie
@ 2016-02-02 14:41 ` Burton, Ross
2016-02-02 14:51 ` Olof Johansson
2016-02-02 15:28 ` Christopher Larson
2016-02-03 6:06 ` Khem Raj
2 siblings, 1 reply; 5+ messages in thread
From: Burton, Ross @ 2016-02-02 14:41 UTC (permalink / raw)
To: Richard Purdie; +Cc: openembedded-architecture, bitbake-devel
[-- Attachment #1: Type: text/plain, Size: 478 bytes --]
On 2 February 2016 at 14:07, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:
> I propose we default to not expanding python code and then deal with
> any consequences from that if/as/where identified. This will improve
> new user understanding and usability of the system, it also allows
> several long standing weird expansion issues to be fixed.
>
As someone who has had to write classes that do "$" + "{FOO}", this gets a
massive +1 from me.
Ross
[-- Attachment #2: Type: text/html, Size: 914 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Openembedded-architecture] [PATCH] build/data: Don't expand python functions before execution [API change]
2016-02-02 14:41 ` [Openembedded-architecture] " Burton, Ross
@ 2016-02-02 14:51 ` Olof Johansson
0 siblings, 0 replies; 5+ messages in thread
From: Olof Johansson @ 2016-02-02 14:51 UTC (permalink / raw)
To: Richard Purdie, openembedded-architecture, bitbake-devel
On 16-02-02 14:41 +0000, Burton, Ross wrote:
> On 2 February 2016 at 14:07, Richard Purdie <
> richard.purdie@linuxfoundation.org> wrote:
>
> > I propose we default to not expanding python code and then deal with
> > any consequences from that if/as/where identified. This will improve
> > new user understanding and usability of the system, it also allows
> > several long standing weird expansion issues to be fixed.
> >
>
> As someone who has had to write classes that do "$" + "{FOO}", this gets a
> massive +1 from me.
Indeed, it's a very welcome change from my point of view! +1
--
olofjn
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] build/data: Don't expand python functions before execution [API change]
2016-02-02 14:07 [PATCH] build/data: Don't expand python functions before execution [API change] Richard Purdie
2016-02-02 14:41 ` [Openembedded-architecture] " Burton, Ross
@ 2016-02-02 15:28 ` Christopher Larson
2016-02-03 6:06 ` Khem Raj
2 siblings, 0 replies; 5+ messages in thread
From: Christopher Larson @ 2016-02-02 15:28 UTC (permalink / raw)
To: Richard Purdie; +Cc: openembedded-architecture, bitbake-devel
[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]
On Tuesday, February 2, 2016, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:
> Right now, if you have some python code like:
>
> X = "a"
>
> def somefunction(d):
> d.setVar("X", "b")
> d.setVar("Y", "${X}")
>
> then any sane person would expect that Y = "b" at the end of the
> function. This is not the case, Y = "a".
>
> This is due to the python function being expanded before execution, the
> executed code would read d.setVar("Y", "a"). This understandably
> confuses people, it also makes it near impossible to write ${} in a
> python function without unintended things happening.
>
> I think there is general agreement we should fix this and standardise
> on non-expansion of python functions. We already don't expand anonymous
> python (mostly).
>
> I've checked OE-Core with buildhistory before and after this change and
> there were a small number of issues this exposed which I've sent
> patches for.
>
> I propose we default to not expanding python code and then deal with
> any consequences from that if/as/where identified. This will improve
> new user understanding and usability of the system, it also allows
> several long standing weird expansion issues to be fixed.
>
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org
> <javascript:;>>
>
I absolutely support this. It should reduce confusion with no loss of
functionality.
Acked-by: Christopher Larson <kergoth@gmail.com>
--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
[-- Attachment #2: Type: text/html, Size: 2204 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] build/data: Don't expand python functions before execution [API change]
2016-02-02 14:07 [PATCH] build/data: Don't expand python functions before execution [API change] Richard Purdie
2016-02-02 14:41 ` [Openembedded-architecture] " Burton, Ross
2016-02-02 15:28 ` Christopher Larson
@ 2016-02-03 6:06 ` Khem Raj
2 siblings, 0 replies; 5+ messages in thread
From: Khem Raj @ 2016-02-03 6:06 UTC (permalink / raw)
To: Richard Purdie; +Cc: openembedded-architecture, bitbake-devel
[-- Attachment #1: Type: text/plain, Size: 2806 bytes --]
> On Feb 2, 2016, at 6:07 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>
> Right now, if you have some python code like:
>
> X = "a"
>
> def somefunction(d):
> d.setVar("X", "b")
> d.setVar("Y", "${X}")
>
> then any sane person would expect that Y = "b" at the end of the
> function. This is not the case, Y = "a".
>
> This is due to the python function being expanded before execution, the
> executed code would read d.setVar("Y", "a"). This understandably
> confuses people, it also makes it near impossible to write ${} in a
> python function without unintended things happening.
>
> I think there is general agreement we should fix this and standardise
> on non-expansion of python functions. We already don't expand anonymous
> python (mostly).
>
> I've checked OE-Core with buildhistory before and after this change and
> there were a small number of issues this exposed which I've sent
> patches for.
>
> I propose we default to not expanding python code and then deal with
> any consequences from that if/as/where identified. This will improve
> new user understanding and usability of the system, it also allows
> several long standing weird expansion issues to be fixed.
I support this too. Additionally, it will be a nice to document this if it has not been done
thus far.
>
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>
> diff --git a/bitbake/lib/bb/build.py b/bitbake/lib/bb/build.py
> index 52a4916..b7c49eb 100644
> --- a/bitbake/lib/bb/build.py
> +++ b/bitbake/lib/bb/build.py
> @@ -239,7 +239,7 @@ def exec_func_python(func, d, runfile, cwd=None):
> """Execute a python BB 'function'"""
>
> bbfile = d.getVar('FILE', True)
> - code = _functionfmt.format(function=func, body=d.getVar(func, True))
> + code = _functionfmt.format(function=func, body=d.getVar(func, False))
> bb.utils.mkdirhier(os.path.dirname(runfile))
> with open(runfile, 'w') as script:
> bb.data.emit_func_python(func, script, d)
> diff --git a/bitbake/lib/bb/data.py b/bitbake/lib/bb/data.py
> index 1f1f0d2..86ad4ed 100644
> --- a/bitbake/lib/bb/data.py
> +++ b/bitbake/lib/bb/data.py
> @@ -308,7 +308,7 @@ def emit_func_python(func, o=sys.__stdout__, d = init()):
>
> write_func(func, o, True)
> pp = bb.codeparser.PythonParser(func, logger)
> - pp.parse_python(d.getVar(func, True))
> + pp.parse_python(d.getVar(func, False))
> newdeps = pp.execs
> newdeps |= set((d.getVarFlag(func, "vardeps", True) or "").split())
> seen = set()
>
>
> --
> _______________________________________________
> bitbake-devel mailing list
> bitbake-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/bitbake-devel
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-02-03 6:07 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-02 14:07 [PATCH] build/data: Don't expand python functions before execution [API change] Richard Purdie
2016-02-02 14:41 ` [Openembedded-architecture] " Burton, Ross
2016-02-02 14:51 ` Olof Johansson
2016-02-02 15:28 ` Christopher Larson
2016-02-03 6:06 ` Khem Raj
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.