<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 13, 2013 at 11:28 AM, Peter Seebach <span dir="ltr"><<a href="mailto:peter.seebach@windriver.com" target="_blank">peter.seebach@windriver.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Sun, 10 Mar 2013 20:39:07 +0000<br>
Paul Eggleton <<a href="mailto:paul.eggleton@linux.intel.com">paul.eggleton@linux.intel.com</a>> wrote:<br>
<br>
> I can't recall if we've discussed this before, but shouldn't we be looking at<br>
> introducing some understanding of list type variables into BitBake itself? If<br>
> BitBake knew the variable was a list it would be possible to have language<br>
> elements that understood how to behave in this situation.<br></div></blockquote><div><br></div><div style>Yeah, this gets brought up from time to time, it's something we've wanted for a while, but nobody has taken the time to make it happen. I would love to see some form of typing go in, and I know Richard has expressed a desire to see this as well in the past.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I rather like this. I would like to have _remove, and it may even make sense<br>
to adopt _remove in the short term, but really I think most of the things<br>
where we're using append/remove should probably be lists, which would also<br>
eliminate the entire category of bugs in which it is unclear whether or not<br>
to add a space.<br>
<br>
Rough thoughts about implementation: Listness could be a flag.<br>
<br>
LIST[list] = " "<br>
LIST = "blah blah blah"<br>
# Oh, hey, what if...<br>
PATH[list] = ":"<br></blockquote><div><br></div><div style>We do have a flag-based typing implementation in the metadata, just not in bitbake itself, see <a href="http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=e4921fd">http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=e4921fd</a> for the original implementation. I particularly like the bits that automatically convert the function signature of the type callback (or class) into a request for additional information via flags. An added required argument to the function = a required flag of that name, same for optional. See <a href="http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/lib/oe/types.py#n27">http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/lib/oe/types.py#n27</a> or <a href="http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/lib/oe/types.py#n13">http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/lib/oe/types.py#n13</a> for examples of that particular implementation.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
or as shorthand:<br>
<br>
LIST = [blah blah blah]<br></blockquote></div><br>I played briefly around with a *really* preliminary prototype of something similar to this. See <a href="https://gist.github.com/kergoth/2788410">https://gist.github.com/kergoth/2788410</a> - any unquoted values are interpreted as json types, and the append/prepend operations are switched to better work with non-string values. It works surprisingly well considering how naive the implementation is, see the functional local.conf snippet in the gist.<br>
-- <br>Christopher Larson</div></div>