[yocto] RFC: User configurable recipe features

[Khem Raj]

On Thu, Oct 13, 2011 at 11:33 AM, William Mills <wmills at ti.com> wrote:
>
>
> On 10/13/2011 04:30 AM, Jack Mitchell wrote:
>>
>> On 12/10/2011 17:59, Darren Hart wrote:
>>>
>>> On 10/11/2011 04:49 PM, Tim Bird wrote:
>>>>
>>>> On 10/10/2011 11:41 AM, Darren Hart wrote:
>>>>>
>>>>> As part of working on meta-tiny, I've come across a need (want?) to
>>>>> present users with the ability to select some set of features in a
>>>>> local
>>>>> configuration file that will impact the build of the image and a set of
>>>>> recipes.
>>>>
>>>> Can you tell me more about meta-tiny?  this is the first I've heard
>>>> about this (sorry if discussion went by on the mailing list and I
>>>> missed it), and I'm very interested.
>>>>
>>>> I'm currently doing some size-related work for Sony (including
>>>> some work to support 4K stacks).
>>>>
>>> Perhaps while I have the attention of a few interested parties, it would
>>> be a good time for a poll. I'm interested in your motivation for smaller
>>> images.
>>>
>>> Are you building SoC's with memory on die and needing to keep the memory
>>> footprint down to save precious die real-estate?
>>
>> no
>>
>>>
>>> Are you looking at creating mass-market products and saving a few
>>> pennies on the flash storage translates to real money, so you want to
>>> minimize the physical size?
>>
>> no
>>
>>>
>>> Are you concerned with boot time, and have connected larger image sizes
>>> with longer boot times?
>>
>> I am concerned with boot time, but don't believe it is image size that
>> ramps it up.
>>
>>>
>>> Is there another motivating factor for your interest in small images?
>>
>> Yes, a smaller system which is easier to check, build and maintain. In my
>> office I am the leading driver for using linux in a team of 3 (two software,
>> one fpga developer) so the less time I spend building, rebuilding and
>> checking features I don't need, to ensure they don't comprimise the
>> stability of the system, the more faith they have in the system I'm putting
>> forward.
>>
>
> Ahhh, nice one Jack.
>
> I had a similar thought this morning.  As the target system gets smaller the
> tolerance for spending X amount of time building non-target code goes down
> and the expectation of being able to use a "modest machine" goes up.
>
> What is a modest machine?  Yocto quotes build times for a "refernce machine"
> that is pretty up to date and not on the low end.  To me, a modest machine
> is the laptop Mom & Dad bought "Stacy" when she graduated from High School
> and went off to College.  Stacy is now a junior and is exploring embedded
> Linux.  This might be an i3 2 GB machine.  A China based startup may also
> give its engineers modest machines.  I think many TI'ers would claim they
> have been stuck on modest machines for long periods.
>
> So If a sato image takes 1 hour to build on the reference machine it may
> take 4 hours to build on a modest machine.  Of that time perhaps 1 hr is
> spent building host side stuff.
>
> If your image is just kernel, busybox, and uclibc you probably only spend
> 1/2 hour building that on a modest machine.  Question is does oe-core/poky
> still make you build 1 hr worth of host stuff?

Usually some of the host distros have sane(for OE sense) versions of
host packages. You might experiment using
ASSUME_PROVIDED for the build host packages this will then use the
packages from your build system
however the results you get might be different than others that's one
reason for host packages

A lot of stuff in OE environment is done to ensure predictability of
builds on different host distros
which is a good thing IMO.

>
> I know Richard's answer will be shared state but I want to see how that
> really works out.  This is an area we plan on playing with over the next
> release cycle.
>
>
>>> Thanks,
>>>
>> _______________________________________________
>> yocto mailing list
>> yocto at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>