[oe] qmake issue

Frans Meulenbroeks fransmeulenbroeks at gmail.com
Mon Jan 4 07:31:06 UTC 2010


2010/1/3 Phil Blundell <philb at gnu.org>:
> On Sun, 2010-01-03 at 17:33 +0100, Frans Meulenbroeks wrote:
>> I can imagine a few solutions, but no idea which one is the best and
>> how to implement them.
>> First option is to hack the generated makefile in a configure_append
>> step. While this would solve the issue for me it is not really a
>> generic solution.
>> Second option is to force removing a package from staging when a new
>> version is build
>> Third option is to change the class which generates the above command
>> to put the -L near the end (after any -L's from the makefile itself.
>
> In the particular case of the myth* libraries, I think they should not
> be getting staged in the first place.  As far as I know, no other
> package uses them for anything.
>
> However, that obviously doesn't solve your qmake problem in the general
> case.  With a bit of luck some Qt hacker will be able to shed light on
> what is really going on there.

Yeah figured out after a brief discussion on #oe that they probably
didn't need to be staged.

Actually the recipe does not contain any staging, so this is a side
effect of the new automated staging.
It could well be that other,  non qmake recipes also suffer from this.

The fix for mythtv is probably to have an empty do_stage()

However as a general rule the -L and -I flags to staging should be
last, not first.
And, ideally, when building a recipe the old contents from that
package in staging should be removed first.
By removing that we avoid the problem that if rX adds a file A to
staging and rY does not do so any more, the file A still remains in
staging (although perhaps incompatible with what rY made.

Frans




More information about the Openembedded-devel mailing list