a38e7ff2810e55455c7ff7b01d4882344b420e18 breaks build and packaged-staging, among other things

a38e7ff2810e55455c7ff7b01d4882344b420e18 breaks build and packaged-staging, among other things

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Looking at
http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=a38e7ff2810e55455c7ff7b01d4882344b420e18
I see:

- -do_stage_append() {
+vala_do_stage_vapi() {
 	install -d ${STAGING_DATADIR_NATIVE}/vala/vapi
 	for VALAFILE in `find . -name "*.vapi" | grep -v
"$VALA_DONT_STAGE_VAPIS"`; do install -m 0644 ${VALAFILE}
${STAGING_DATADIR_NATIVE}/vala/vapi/; done
 	for VALAFILE in `find . -name "*.deps" | grep -v
"$VALA_DONT_STAGE_VAPIS"`; do install -m 0644 ${VALAFILE}
${STAGING_DATADIR_NATIVE}/vala/vapi/; done
 }
+
+EXPORT_FUNCTIONS do_stage_vapi
+
+addtask stage_vapi after do_populate_staging before do_package

Attentive readers will see that anything using vala.bbclass will now
stage things needed for downstream dependencies outside of do_stage
*and* do_install()

This means that doing

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.

The other problem is that the packaged-staging packages won't contain
the vapi files, so rebuilding staging it broken as well.

So all in all: please revert that.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFL1JowMkyGM64RGpERAnRZAJ4qt9DIkXen+f8KTqp9yWE7YZfibQCdHUAo
mS3KolPmIvCmOv1F4GHzPS4=
=UAn/
-----END PGP SIGNATURE-----

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

[Graeme Gregory]

Im sorry I dont know vala at all, but should those VAPI files be put
into -dev packages? basicall add a do_install_append and a FILES=

Doing so would make them appear automagically in staging anyway.

Graeme

On Sun, Apr 25, 2010 at 09:38:24PM +0200, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> Looking at
> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=a38e7ff2810e55455c7ff7b01d4882344b420e18
> I see:
> 
> - -do_stage_append() {
> +vala_do_stage_vapi() {
>  	install -d ${STAGING_DATADIR_NATIVE}/vala/vapi
>  	for VALAFILE in `find . -name "*.vapi" | grep -v
> "$VALA_DONT_STAGE_VAPIS"`; do install -m 0644 ${VALAFILE}
> ${STAGING_DATADIR_NATIVE}/vala/vapi/; done
>  	for VALAFILE in `find . -name "*.deps" | grep -v
> "$VALA_DONT_STAGE_VAPIS"`; do install -m 0644 ${VALAFILE}
> ${STAGING_DATADIR_NATIVE}/vala/vapi/; done
>  }
> +
> +EXPORT_FUNCTIONS do_stage_vapi
> +
> +addtask stage_vapi after do_populate_staging before do_package
> 
> Attentive readers will see that anything using vala.bbclass will now
> stage things needed for downstream dependencies outside of do_stage
> *and* do_install()
> 
> This means that doing
> 
> 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.
> 
> The other problem is that the packaged-staging packages won't contain
> the vapi files, so rebuilding staging it broken as well.
> 
> So all in all: please revert that.
> 
> regards,
> 
> Koen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
> 
> iD8DBQFL1JowMkyGM64RGpERAnRZAJ4qt9DIkXen+f8KTqp9yWE7YZfibQCdHUAo
> mS3KolPmIvCmOv1F4GHzPS4=
> =UAn/
> -----END PGP SIGNATURE-----
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

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

[Michael 'Mickey' Lauer]

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?

-- 
:M:

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

[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).
Think of vapi files as m4 macros and you'll see why the current and
previous situation are completely wrong.

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFL1TRsMkyGM64RGpERAu55AJ4x6nIQFKdpxG3eTlDj/TPkJXGQ3gCfXA4p
Cte/6tg05/eQ+k7cBVyOCyg=
=J875
-----END PGP SIGNATURE-----

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

[Michael 'Mickey' Lauer]

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: