[Development] Qt 6 buildsystem support requirements

[BogDan Vatra]

Hi,
În ziua de duminică, 22 iulie 2018, la 12:11:44 EEST, Tobias Hunger a scris:
> On Sat, Jul 21, 2018, 07:38 Bogdan Vatra via Development <
> 
> development at qt-project.org> wrote:
> > You really hate QBS don't you ? :)
> 
> Do you have so few arguments for qbs that you need to appeal to emotions? :)
If it works why not, I'm using all the weapons I have. :-P 

>
>> Anyway IMHO is more important to have a clean, nice and easy to use syntax
> > and
> > to be tooling friendly than 1.b.
> 
> Sure you can write toolable build files with qbs, but there is nothing
> stopping you writing an unparsable JS mess either.

Hehe of course you can write messy JS, but at least it doesn't hurt your eyes 
when you read it and in the morning you don't wake up screaming.

> For QML we needed to define a toolable subset of the language with the UI
> files to have any chance at tooling it. For the qbs dialect of QML that has
> not been done yet. So I do not consider qbs to be toolable at this point.

By tooling friendly I mean basic stuff:
 - create (sub) projects, this part is mostly handled by QtCreator with the 
wizards templates, but the build system still needs to add it the the parent 
project.
 - add targets (executable, static & dynamic libs) to (sub) projects
 - add/remove files to a (sub)project target.
 - get all the info about every source file of the (e.g. all compiler flags), 
cmake with the server thing can handle this task properly these days.
 - parse the project and report in an easy for IDE way all the project parts 
(files, (sub) projects, targets, etc.). Same as above, thanks to cmake-server, 
QtCreator gets all the info properly.

Last time I checked it, QBS can handle all those things not only a few.

What QBS is missing are toolable properties (similar with cmake ones) which 
can be used to turn on/off different parts of the project or set other stuff 
needed by a big projects like Qt (e.g. git version).

Going much deeper than this, we'll have to either create super complicated 
parsers as you mentioned or we'll have to use xml/json/etc. in a non (easily) 
readable by humans forms.

Cheers,
BogDan.