[Qbs] Language Proposal: A generic `Item{}` for classifying bindable objects

Иван Комиссаров abbapoh at gmail.com
Tue Sep 6 15:38:49 CEST 2022

> Why would the item pool use `std::vector<Item *> m_items;` instead of a QList ( Or QVector ) ?  I imagine it was a performance consideration, but it always puzzles me to see stdlib in most qt code.
There were plans to migrate to pure stdlib and some parts of the code have been ported already which leads to unnecessary convertions in some places.
Also, most of the time we do not need QVector’s COW and we don’t need to write qAsConst on containers.
I generally use std containers in new code unless we benefit from COW to save some memory

> Should Project and Product remain the only top level Items? Or would there be reason to let GenericItem{}​ do so also? I am thinking to keep it as is.
Probably those should be left as is.

> There are three Values -- Item, JSSource, and Variant. I have only been able to create JSSource when making a qbs file. What are the other two used for?
Product {
    name: "p"
    property string foo: "foo"; // this is jsvalue UNLESS it is overriden from CLI, e.g. 'qbs resolve products.p.foo:bar’, in that case it is Variant Value

    Depends { name: «cpp» }
    property string bar: cpp.defines // cpp here is an ItemValue, while cpp.defines is a js or variant value as above

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qbs/attachments/20220906/fbe45f3a/attachment-0001.htm>

More information about the Qbs mailing list