Age | Commit message (Collapse) | Author | Files |
|
As discussed on the mailing lists, using a suffix to package names is
hard and has lead to many recipes having to do PKGSUFFIX games. Its
looking extremely hard to scale nativesdk much further without hacking
many recipes.
By comparison, using a prefix like multilib does works much better and
doesn't involve "hacking" as many recipes. This change converts nativesdk
to use a prefix using the existing multilib infrastructure.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
populate_sdk was renamed to populate_sdk_base in order to allow for changes
that may break existing SDK recipes. Any such changes need an analog
in populate_sdk (new version) to restore previous desired behavior.
In addition to the rename, one minor change was made. The _base version
only had the do_populate_sdk as an added task, but no before or after defined.
For compatibility, populate_sdk has do_populate_sdk defined as "after"
do_install and before do_build, this is identical to the original behavior.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
|
|
When a recent change, the path to log files may be contained within an
arbitrary directory. To generate the manual log files in the correct path
we should be using the ${BB_LOGFILE}'s path instead of always assuming the
logs go into ${WORKDIR}/temp.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
|
|
This fixes the issue below:
| Generating solve db for /local/home/mattsm/git/poky/build_p4080ds_release/tmp/deploy/rpm/all...
| total: 1 0.000000 MB 0.093784 secs
| fingerprint: 9 0.000012 MB 0.000252 secs
| install: 3 0.000000 MB 0.039092 secs
| dbadd: 3 0.000000 MB 0.034837 secs
| dbget: 12 0.000000 MB 0.000062 secs
| dbput: 3 0.009532 MB 0.002731 secs
| readhdr: 31 0.019160 MB 0.000084 secs
| hdrload: 15 0.027924 MB 0.000116 secs
| hdrget: 494 0.000000 MB 0.000691 secs
| Processing task-core-standalone-sdk-target...
| Processing glib-2.0...
| Unable to find package glib-2.0 (glib-2.0)!
| ERROR: Function 'do_populate_sdk' failed (see /local/home/mattsm/git/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/fsl-toolchain-1.0-r6/temp/log.do_populate_sdk.16975 for further information)
If you have:
TOOLCHAIN_TARGET_TASK += "glib-2.0"
The package name was not getting remapped correctly for the do_populate_sdk
case.
Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If we don't do this, the SDK target sysroot is named generically even
when it contains package architecture specific optimisations.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
[YOCTO #892]
Use the new cached site config files generation mechanism in
toolchain-script.bbclass.
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
|
|
Add SDK_PACKAGE_ARCHS to avoid the sed operations we were previously doing
inside of the variouns populate_sdk functions and related items.
Also add documentation to populate_sdk to explain when the various functions
are expected to be doing.
Finally fix a bug in populate_sdk_rpm where the wrong value was being set,
noticed while working on this change.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
|
|
contents of the task represent
This is particularly important since the file doens't use BBCLASSEXTEND
and PN is therefore misleading
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
moving common code between populate_sdk.bbclass and meta-environment.bb
into toolchain-script.bbclass.
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
|
|
Move the populate_sdk task out of meta-toolchain. Made it more generic
to support rpm/deb package format.
This commit is dependant on a series of commit:
2ea0406e4516fc59dff86cb4adc35c82cb774c2f
7ffa45b7cfea24dae1b51f40cfc807bf78b21b66
bf201a74c243942af3fcae6f174496bdd819dbc0
3d29933f2925efe8a84f10efdf50396031c33ae4
3d29933f2925efe8a84f10efdf50396031c33ae4
9c724dbf57e610a9e06bbdce38383dee3ac49281
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
|