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 _______________________________________________ QBS mailing list QBS@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs