Re: a38e7ff2810e55455c7ff7b01d4882344b420e18 breaks build and packaged-staging, among other things

[Michael 'Mickey' Lauer <mickey@vanille-media.de>]

Am Montag, den 26.04.2010, 08:36 +0200 schrieb Koen Kooi:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 26-04-10 00:35, Michael 'Mickey' Lauer wrote:
> > Am Sonntag, den 25.04.2010, 21:38 +0200 schrieb Koen Kooi:
> >> bitbake something-depending-on-vala-stuf
> >>
> >> is now broken because bitbake will run
> >> something-depending-on-vala-stuf.do_configure and compile after
> >> vala-stuff.do_populate_staging and the vapi files will NOT be there.
> > 
> > Can you give a concrete example that breaks? I'm using quite a
> > substantial amount of Vala e.g. in task-fso2-compliance and it builds
> > from scratch without any problems.
> > 
> >> The other problem is that the packaged-staging packages won't contain
> >> the vapi files, so rebuilding staging it broken as well.
> > 
> > Ok, since the patch was made to get rid of all the 'legacy staging'
> > warnings, would do_install_append() instead of do_stage_vapi() fix that?
> 
> No, since you can't poke outside ${D} in do_install. I think the best
> solution is to have the vala compiler look in the arch dir it's
> compiling *for* instead of the host one (STAGING_DIR instead of
> STAGING_DIR_NATIVE).

I agree that would be the best way, but it's not an option for now.

> Think of vapi files as m4 macros and you'll see why the current and
> previous situation are completely wrong.

True, but sometimes we have to work around upstream things in the build
utilitiy. Oh well, I don't mind the legacy staging warnings - so if no
one has any other idea, I'll revert it back to the legacy staging later
today.

-- 
:M: