[yocto] QMake & externalsrc incompatible?

Paul Eggleton paul.eggleton at linux.intel.com
Wed Sep 18 02:41:22 PDT 2013


On Wednesday 18 September 2013 10:47:56 Anders Darander wrote:
> * Brad Litterell <brad at evidence.com> [130917 21:20]:
> > I have a number of QT components that have qmake style .pro files.
> > 
> > In my recipe I inherit both externalsrc & qmake2.  I'm using qmake2 based
> > on the quicky sample recipe since I don't need X11 or the other GUI
> > libraries.
>
> I've got a similar recipe setup for some of my coworkers. The main
> difference being that we're inheriting qt4e instead of qmake2.
> 
> > In the bitbake work folder, the generated run.do_configure script
> > resembles
> > this:
> > 
> > cd /home/brad/ecom/build/toolchain/work/.../ecomapi-2.0-r0/ecomapi-2.0/
> > ...
> > PROFILES="`ls *.pro`"
> > 
> > This is the location where a tarball would normally be unpacked, but in
> > this case I'm using externalsrc and the source files are not here. 
> > Therefore the ls *.pro doesn't return anything for the automatic profile
> > detection and the build fails.
> > 
> > My recipe is very simple (removing the description & licensing):
> > 
> > PV = "2.0"
> > inherit externalsrc qmake2
> > S = "${OEBASE}/ecomapi"
> 
> To make it work correctly, I used:
> 
> S := "${THISDIR}/chargemanager"
> B := "${S}"
> 
> You shouldn't need to use :=, I was required to do that as I needed to
> use THISDIR (and thus I need the expansion to occur immediately).
> 
> Just setting S wasn't enough for me, I needed to also define B. Note,
> though, that this means that you can't build your recipe for multiple
> arch's etc.

This just looks like the value of PROFILES in qmake_base.bbclass needs to be 
fixed to look in ${S} instead of the current directory (which would be ${B}). 
I'm not sure if any other tweaks would be needed for qmake to allow S != B 
though.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre



More information about the yocto mailing list