[QBS] how to use qbs in huge projects

[Christian Kandeler]

On 10/09/2014 04:46 PM, Kurt Keller wrote:
>>> By implementing a qbs hierarchy like this, I encounter the following
>>> problems:
>>>     - qtcreator needs ages to load the qbs file in the base directory
>>> (50+ sub-qbs files)
>
>> I don't know what "ages" means. If you use a release build of Creator
> (built
>> against a release version of Qt, more importantly), things should be
> reasonably fast.
>
> "ages" means up to 60 seconds on Intel I7 / 16 GB Mem / SSD Hard Disk / Win
> 8/64
> Qt Creator & Qt are release builds. (There are in one case more than 3800
> C++
> Source files and some  1100 C++ Header files referenced by the main QBS
> file.)

Qt Creator is of comparable size and takes a little more than ten 
seconds to load on my somewhat older Windows machine. It's hard to say 
from here why it's so slow for you.

>>>     - once qtcreator has parsed the complete qbs hierarchy, I could not
>>> find a way
>>>       to compile & debug a subproject only. (i.e. "set as active
>>> project" is not available)
>
>> Right-click on any project in the tree, click "Build".
>
> Yes, building is not the problem, but how to debug (execute) such a sub
> project
> application?

You are aware of run configurations, right? You can choose them either 
via the target selector or via the "Run" part of the Projects pane.

>>>     - in addition I want to be able, to do: 'cd subproject/subsubproject;
> qbs'
>>> in a cmd
>>>       window which is not possible, because subsubproject does not know
>>> the properties
>>>       of higher level projects.
>
>> Same thing. But even if it does work, you should be aware that this build
> is
>> entirely separated from any build of the top-level project, so that seems
> like
>> a rather questionable thing to do anyway. Instead, you should probably run
>
>> qbs for the top-level project and select the products you are interested
> in.
>> Admittedly, we don't have a "--projects" switch analagous to "--products",
>> but this could be implemented.
>
> This is another annoying point. When 'qbssing' in the middle of the project
> tree (i.e. to compile a set of libraries which belong together) qbs creates
> a
> build directory in the working directory. After a while there are lots of
> build directories - scattered over the whole directory tree.

Well, that's simply not the intended usage pattern.

> Would you always call qbs in the qt root directory, when doing a bug fix
> in qlist.cpp?

Sure. Opening the sub-project is a crutch people use because recursive 
make is slow. That's not applicable to qbs.

>>> So I created modules, to store 'global properties'. My
>>> sub{sub+}projects depend on this modules and know therefore the
>>> 'global' properties. But as soon as relative pathnames (upward paths,
>>> like '../../../include' or '../../lib/Debug') are used, this practice
>>> does not work very well. ('cd subdir; qbs' will not work (cannot find
>>> include files) while 'cd subdir/subdir/subdir; qbs' will find the
>>> include files or vice
>>> versa)
>>> Switching to absolute path names is a problem too, because there is a
>>> base dir for every release of the project. (project-5.0, project-5.1,
>>> ...) So I have to change all absolute path names when starting a new
>>> release...
>
>> I didn't understand this. You aren't saying you're anchoring your relative
>
>> paths at the working directory, are you?
>
> Yes I do. How can I anchor upward paths (../../public/include/files) on
> anything else? How can I get (in a module) the absolute path of my
> current qbs working directory?

Your module should never care about any working directory; that's simply 
wrong and cannot work at all if you use, for instance, the -d option. 
You probably want project.sourceDirectory.


Christian