On 12/14/12 21:57, Brian Hutchinson wrote:
On Fri, Dec 14, 2012 at 4:09 PM, Zhang, Jessica <jessica.zh...@intel.com> wrote:
Actually I talked with Richard regarding retiring the toolchain targets
(meta-toolchain and meta-toolchain-gmae) as Mark mentioned that now we can build a
toolchain matching the >image. Also, we're continue improving adt-installer which
also allows you to setup sysroot using the target image as well. Richard's concern
is there maybe some legacy user that >preferred the toolchain target. With the
latest changes in toolchain generation which really maps to target images, probably
we should unplug to legacy ones to make the toolchain generation more streamline.
Thoughts or concerns?
I'm one of the users that is stuck using Edison 6.0. I'm desperate
for the ability to generate a toolchain and sysroot that matches our
target. Right now I have to build meta-toolchain and then manually
look in the tmp for sysroot-destdir related stuff from our build and
copy it to the sysroot in /opt/poky and hand that out to developers.
When our sister group overseas makes a change that effects the sysroot
it breaks our build and I have to figure out what happened and
manually adjust our sysroot to fix the problem. I sure would like to
be able to just do an update and then bitbake the toolchain to pick up
the changes. I figure we are stuck with Edison for a while ... can I
back port these toolchain features you all are talking about to
Edison?
Hi Brian,
I may be missing a trick here, but for our internal toolchain I pretty
much made a copy of meta-toolchain, made a copy of the
toolchain-packagegroup, edited the package group to contain the same
libs, apps etc as my image, pointed meta-toolchain copy to that
package-group instead of the default and now when ever I make an update
to the image it is just a case of running
bitbake core-image-product meta-toolchain-product
and that spits out both the image and customized toolchain. If I have
missed something obvious then please excuse my ramblings :)
Cheers,
Jack.
Regards,
Brian
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
