Important: Please read the Qt Code of Conduct -

Qbs Automatic Projects

  • For a long time I was using qmake in a forgetful manner. Letting Qt Creator do all the work when adding files or linking libraries and only editing it to make it do something "extra" like installing files. The main reason was that it was easy to make errors and hard to debug. So eventually I "templatized" pretty much all of my project's *.pro files into few functions defined in a *.pri file so the actual *.pro files shrinked to be just an import and invocation of one or two of those functions to se everything up. The main benefit was that once I got it right it was always right. I also did not have to edit loads of pro files when I wanted to make a structural change or add something or shuffle things around. Few edits in a *.pri that propagated everywhere. And then I tried Qbs and immediately recognised it had even bigger potential for automating project definitions except... it discourages doing that (see for example this and quite a few other instances where such approach is discouraged). I honestly do not understand why. What does it bring me to type out the same thing over and over again? You would not do it in your code. You would make a method or class or at least a loop. Yet for some reason I am supposed to do that with project files...

    Anyway, after lengthy introduction to the real thing. The discouragements did not stop me as I really wanted to make truly automatic Qbs projects so I did! It could be easily adapted to different structure and expanded to even more modular and smarter system that could potentially automatically detect type of the projects and other things.

    Model scenario

    • A library collection containing multiple modules (libraries), tests, documentation, public include folder and custom install destination (like Qt itself) could perhaps be structured as follows:
      /dev/AwesomeProject/build <-- dedicated build directory
      /dev/AwesomeProject/build/qbs <-- qbs project file(s) goes here
      /dev/AwesomeProject/bin/ <-- binaries should be installed here
      /dev/AwesomeProject/bin/windows-64bit-msvc <-- sensible target name for installing
      /dev/AwesomeProject/include/ <-- public headers root
      /dev/AwesomeProject/include/SubProject1/ <-- public headers go here
      /dev/AwesomeProject/include/SubProject2/ <-- dtto
      /dev/AwesomeProject/src/ <-- sources go here
      /dev/AwesomeProject/src/SubProject1/ <-- source files here
      /dev/AwesomeProject/src/SubProject1/doc/ <-- documentation here
      /dev/AwesomeProject/src/SubProject1/private/ <-- private classes, using PIMPL right?
      /dev/AwesomeProject/src/SubProject1/tests/ <-- tests go here
      /dev/AwesomeProject/src/SubProject2/ <-- dtto

    And with this single file you would have to do zero manual steps to build it:

    What this does is it will assume the above structure, scan through it and build projects based on what it found. It will read files, extract include directives and match them to Qt modules (wip) and other projects and correctly assign dependencies and include directories. It will automatically pick up tests and create appropriate project definitions for them and will add documentation project as well. The resulting projects are written and loaded as if you have written them yourself. Except you did not have to.

    It can be easily adapted to different structure or to perform even more tasks like project type detection (Qt, App, Lib, static Lib etc.) or making it scan projects recursively if you had deeper structure that in this example. And of course you can always go and edit stuff manually, use it just for generating boilerplate stuff or whatnot.

    But the point is that I believe this is what Qbs should really consider focusing on. Allowing people to define complex projects with ease and few lines of code if they follow some structure of their choosing (and thus also enforcing it, which is good).

    My 2 cents and keep up the good work!

  • Lifetime Qt Champion


    Interesting and thorough analysis. I'd recommend bringing this to the Qbs mailing list. Your find there Qbs developers/maintainers. This forum is more user oriented.

Log in to reply