Hello, regarding the question of Tino Pyssyalo: we at Diehl Aerospace have switched to Qbs in the research department for all new software projects.
Recently, we also moved a "legacy" project to Qbs which involved project-specific build tools and multiple target architectures combined in a single build (which we solved using make to trigger qbs multiple times; no use of qbs multiplexing yet), as well as packaging for Debian. Before, this project used a non-recursive makefile-based build system, which had good performance but grew a little difficult to maintain. Main reasons for the switch to Qbs were: * its good integration with Qt Creator: that the clang backend gives good autocompletion and warning/error "forecast" because it knows exactly how source files will be compiled (#defines, compiler switches etc), and the Qt Creator project file is identical to the build definition * its scalability for larger projects * its extendability: A tool (like a custom compiler) can define a Qbs module which can then be imported by other projects Now that we progressively move to larger teams working with Qbs, I think the most interesting issue will be how much every developer needs to know about Qbs in order to participate in a project. Using it involves quite some learning effort, and it definitely does have its pitfalls. Best regards, Uwe -- Uwe Salomon Technical Project Manager Diehl Aerospace An der Sandelmuehle 13 60439 Frankfurt Germany Phone: +49 69 5805-1731 Email: [email protected] _______________________________________________ Qbs mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qbs
