[U-Boot] [PATCH] libfdt: fix build with Python 3

[Stefan Agner]

On 2017-04-05 10:26, Stefano Babic wrote:
> Hi Stefan,
> 
> On 04/04/2017 20:44, Stefan Agner wrote:
>> On 2017-04-04 01:53, Stefano Babic wrote:
>>> Hi Stefan,
>>>
>>> On 03/04/2017 23:02, Stefan Agner wrote:
>>>
>>>> But then, I don't expect that "/usr/bin/env python" is looking at
>>>> PYTHON.
>>>>
>>>> As far as I understand env, it just looks up the current environment to
>>>> run its COMMAND argument.
>>>
>>> Agree, this is also mz understanding.
>>>
>>>> It is helpful as a shebang, but it does not
>>>> seem to make any difference to calling "python" directly (since that
>>>> also just looks up the current environment PATH and executes the first
>>>> python it finds...
>>>
>>> Agree - so that is disturbing is the fix calls to "python" inside
>>> Makefile. That means it remains to change:
>>>
>>> tools/_libfdt.so: $(patsubst %.o,%.c,$(LIBFDT_OBJS)) tools/libfdt_wrap.c
>>> 	LDFLAGS="$(HOSTLDFLAGS)" CFLAGS= python $(srctree)/lib/libfdt/setup.py
>>>
>>> to:
>>>
>>> tools/_libfdt.so: $(patsubst %.o,%.c,$(LIBFDT_OBJS)) tools/libfdt_wrap.c
>>> 	LDFLAGS="$(HOSTLDFLAGS)" CFLAGS= ${PYTHON} $(srctree)/lib/libfdt/setup.py
>>>
>>
>> On my host
>>
>> $ echo Python is \"$PYTHON\"
>> Python is ""
>>
> 
> Sent a patch today, easier to test.
> 
> The thing is that PYTHON is set into the main Makefile as "python", and
> this should not break your build. At least, I hope so...
> 

Ok, yeah I guess than its fine to do such a change.

>> Wouldn't that break regular builds? Probably wouldn't since shebang
>> kicks in, but is that really what we want?
> 
> The main Makefile already sets most tools to default if they are not
> current set. This should ensure that the normal build works, but should
> even allow to override it from command line - or adding EXTRA_OEMAKE in
> recipe.
> 
>>
>> What I thought OE was doing is adding the native/x86_64 sysroots in your
>> path at the beginning,
> 
> Right.
> 
>> which should already make sure that a regular
>> "python" call executes OE python...
> 
> "nativepython" should have a symbolic link to "python", but what I noted
> is some mix between distro and SDK.
> 

And that symlink is part of the path, so in a OE environment, "python"
really should call the nativepython implementation...?

What do you mean by mix between distro and SDK?


>> But maybe there is more to it,
>> especially since setup.py even compiles things...
> 
> Right. I have seen in some recipes that /usr/bin/env is replaced, for
> example:
> 
> meta/recipes-support/createrepo/createrepo_0.4.11.bb:		sed -i -e
> 's|^#!.*/usr/bin/env python|#! /usr/bin/env nativepython|' $i
> 
> There are a few of recipes doing this.
> 
>>
>> Maybe we need to peek into distutils/setuptools class to understand how
>> that works for regular Python modules:
>> https://github.com/openembedded/openembedded/blob/master/classes/setuptools.bbclass
>> https://github.com/openembedded/openembedded/blob/master/classes/distutils.bbclass
> 
> But there are for building python-modules, and we are just simply want
> to build u-boot. Then, if I understand your concept, we need to build a
> python module outside u-boot, and built before u-boot (ok, I am just
> thinking about Yocto build..), as nativesdk-pythonsetuppy or whatever,
> and this is just called when u-boot is built. But this makes things much
> more complicated...

I guess there is a reason why we build that module as part of the U-Boot
build, probably because later steps use the module to script some
automation...? So yeah, agreed we should not split that out.

My point was more that those classes could be a source of inspiration
how OE handles building Python modules in a sysroot...

--
Stefan