[QBS] how to use qbs in huge projects

[Christian Kandeler]

On 10/08/2014 05:08 PM, Kurt Keller wrote:

 > My projects are structured in sub directories: starting from a base
 > directory
 > there are subdirectories for binaries (debug and release, libraries
 > (.so, .dll) and  .lib and .pdb files) as well as a subdirectory
 > structure for application and library source code.

This sounds weird already. The binaries should not be considered part of 
your project tree.

> I understand the concept, that there should be one qbs file in the project
> base
> directory, which defines properties and references the qbs files in
> subdirectories
> which in turn inherit these properties and so on.
>
> 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.

>    - 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".

>    - it is not possible, to open subprojects directly with qt creator:
>            qtcreator subproject/subsubproject/subsubproject.qbs
>      there always will be some properties missing.

If you access parent project properties inside your project, then you 
are declaring that that project cannot live on its own. Whether or not 
that is the right decision depends on your project.

>    - 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.


> 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?


Christian