On Sat, Aug 22, 2015 at 6:08 AM, Richard Purdie
<richard.pur...@linuxfoundation.org> wrote:
> On Fri, 2015-08-21 at 23:03 -0700, Khem Raj wrote:
>> > On Aug 21, 2015, at 2:58 PM, Otavio Salvador 
>> > <otavio.salva...@ossystems.com.br> wrote:
>> >
>> > On Fri, Aug 21, 2015 at 6:49 PM, Khem Raj <raj.k...@gmail.com> wrote:
>> >>
>> >>> On Aug 21, 2015, at 2:38 PM, Otavio Salvador <ota...@ossystems.com.br> 
>> >>> wrote:
>> >>>
>> >>> The 'BRANCH' variable name has no explicit relation with the
>> >>> SRC_URI. Using 'SRC_BRANCH' makes it more obvious and easier to
>> >>> identify.
>> >>
>> >> Look good to me, just may be avoid ‘_’ and call it SRCBRANCH
>> >
>> > I did this initially but looking at how it looks in the source code,
>> > it seems SRC_BRANCH makes easier to spot the relation with SRC_URI. So
>> > I took the second.
>>
>> since bitbake use ‘_’ as a override separator, its less confusing if 
>> variables don’t have underscore in them
>> for future collision.
>
> Names with '_' in them might look better but there is a small price to
> pay for it in that bitbake then has to track whether "BRANCH" is an
> override. Obviously it does this in many cases already (e.g. URI from
> SRC_URI) but when you've looked at what the datastore actually has to do
> to keep the system working, you start to lean against creating more work
> for it.
>
> I continue to believe we should probably find a better syntax for
> overrides. If someone had a good alternative, it would probably be worth
> the pain of switching...
>
> I'm not saying we shouldn't take the above patch here, just that this is
> something which does have a cost and all the uses do mount up
> significantly.

So we should consider renaming SRC_URI for SRCURI. ;-)

I am Ok sending it as SRCBRANCH but it does looks less obvious for news comers.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Reply via email to