[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