[Buildroot] [PATCH] Add pyside + shiboken packages

[Thomas Petazzoni]

Dear Thierry Bultel,

(Thanks for resending the message to the list! As a further improvement
next time, it'd be great if you could avoid top-posting.)

On Sat, 21 Sep 2013 07:41:42 +0200, Thierry Bultel wrote:

> I will pay more attention to my patch formatting in the future,
> the lesson from that is that I cannot trust thunderbird for doing the
> things right.

I believe Thunderbird can be taught to do the right thing, but it's
quite certainly far more convenient to configure 'git send-email' once
for all, and enjoy scripted sending of patches. For example, since
you'll have to split this patch in at least 3 patches, you'd have to
manually send 3 e-mails with Thunderbird. git send-email would them all
of them automatically for you.

> My first approach was to use Cmake infrastructure indeed.
> The most annoying thing with shiboken and pyside CMakefiles is that
> it seems really a pain in the neck to have proper paths set,
> my fault here is to have not put enough comments around the
> various hacks I had to do to cope with it.

If they are CMake based packages, then they should use the
cmake-package infrastructure. Of course, if they have some tricky
aspects, we might need to adapt/improve the cmake-package
infrastructure if needed.

> I will start from scratch and try to possibly better fit in the model,
> and keep you in touch of what I see, if you don't mind.
> 
> About the BR2_PACKAGE_PYTHON_PY_PYC:
> 
> There are 2 issues when not having it
> 
> 1)
> host/usr/arm-buildroot-linux-gnueabi/sysroot/lib/python2.7/site-packages/PySide/__init__.py
> gets removed.
> I agree that setting the option for just one file if a shame but ...

Hum, I guess the problem is that the .py files installed by PySide
don't get compiled into the pyc bytecode? It'd be great to investigate
why, but as a temporary solution, we can disable the PySide package
when only .pyc files are kept (i.e do the opposite of what you did:
instead of preventing the .pyc only option to be enabled when pyside is
enabled, you prevent pyside from being enabled when the .pyc only
option is enabled. The reasoning is that the user certainly select
python before choosing the specific Python modules he wants to install).

> 2) The aim of pyside is to run python code (compiled or not, and that 
> may call libraries in pyc).
> So if the user python application is part of buildroot it would be
> removed from the target as well.

A Python application is usually made of two parts: one Python script
installed in /usr/bin, without any .py extension, so that it appears
like a normal executable. Regardless of the Python .py only / .pyc only
configuration, this file will be kept. The second part is a Python
module, which normally should get byte-compiled, and therefore
have corresponding .pyc files.

> About your comment on "HOST_PYSIDE_BUILD_CMDS or HOST_PYSIDE_CONFIGURE_CMDS"

When you make a comment, what about replying by quoting the relevant
part of the e-mail? :-) It would make things easier to follow. See
http://en.wikipedia.org/wiki/Posting_style#Bottom-posting.

> I think you made a confusion, and this is likely because my patch is too 
> big.
> The host variant is needed for pyside-tools, not for pyside.

Ah, yes, I referred to the wrong package. What I should have said is
that: package/pyside-tools/pyside-tools.mk contains a $(eval
$(host-generic-package)) to declare a host variant, but there is no
HOST_PYSIDE_TOOLS_BUILD_CMDS or HOST_PYSIDE_TOOLS_INSTALL_CMDS or
HOST_PYSIDE_TOOLS_CONFIGURE_CMDS, so essentially, the host-pyside-tools
package cannot work (if ever needed).

> As I said in my (too short) comment, the host variant is needed for
> shiboken, in order to get the generator that is used by the build.

The host variant of pyside-tools?

> After that, a target shiboken library is needed as well, that leads to
> building it twice ...
> 
> I think that the shiboken Cmake is not completely "cross-build" proof,
> and that is the main difficulty to deal with.
> The fact that it calls the target  'shiboken' binary for itself
> illustrates that.
> (but for that point it was "easy" to workaround with 
> SHIBOKEN_PRE_CONFIGURE_GENERATOR_PATH)

It happens for quite a few packages that the package needs a part of
itself to build the rest, which causes problems in cross-compilation
mode. In that kind of cases, we usually have two possible solutions:

 (*) If what is needed during the build is also needed in the final
     result on the target, then the best option is to build a host
     variant of the package, and tweak the build system to be able to
     point to this host variant while building the target variant (which
     is what you've done, and I think is fine).

 (*) If what is needed is just a tool used at build time, then
     sometimes we just build this tool manually prior to starting the
     build.

Best regards,
-- 
Thomas Petazzoni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com