[QBS] how to use qbs in huge projects

[Kurt Keller]

> Christian Kandeler wrote:
>> 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 cannot understand this. Why weird? It should be my decision where I keep
my 
binaries - not a qbs decision. We keep all binaries inside the project tree
during 
a normal development cycle. Once a release is finished, a special 'install'
step 
moves the (selected) binaries which are for customer installation onto
special 
machines, where setups and rpms are made.

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

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

>>    - 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? In visual studio I could set an active project. In Qt Creator I
can only
select the main qbs project file as a active project not a sub project.

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

Yes, I agree.

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

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

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

I would really appreciate a solution for this. Otherwise I see only the 
possibility, to have qbs files in the leave projects and control all sub
projects above the leaves by shell scripts and .bat files, which is even 
worse than tmake. (We used 15-year old tmake before we switched
to qbs)

> Christian

Kurt.