From qbs at gudrian.org Sat Jun 6 18:30:38 2020 From: qbs at gudrian.org (Christian Gudrian) Date: Sat, 6 Jun 2020 18:30:38 +0200 Subject: [Qbs] Evaluation of Conditional Depends Message-ID: <00D085B2-1213-46EA-A8B2-757B86F7860A@gudrian.org> Hello! In ModuleA there is a property enableFeature which by default is false. ModuleB conditionally depends on ModuleC, if ModuleA.enableFeature is true. A Product depends on ModuleA and ModuleB and sets ModuleA.enableFeature to true. However, ModuleC is not used as a dependency. I assume this is expected behaviour, because otherwise it might be impossible to reach a stable dependency graph. But how can I achieve what I’m trying to do here? Thanks! Christian From richard at weickelt.de Sun Jun 7 01:03:57 2020 From: richard at weickelt.de (Richard Weickelt) Date: Sun, 7 Jun 2020 01:03:57 +0200 Subject: [Qbs] Evaluation of Conditional Depends In-Reply-To: <00D085B2-1213-46EA-A8B2-757B86F7860A@gudrian.org> References: <00D085B2-1213-46EA-A8B2-757B86F7860A@gudrian.org> Message-ID: <36286d76-f59d-3c8e-988e-2ac490421e58@weickelt.de> > In ModuleA there is a property enableFeature which by default is false. > > ModuleB conditionally depends on ModuleC, if ModuleA.enableFeature is true. > > A Product depends on ModuleA and ModuleB and sets ModuleA.enableFeature to true. However, ModuleC is not used as a dependency. Could you clarify the relationship between ModuleA and ModuleB? Maybe post some minimal example code. From chgans at gmail.com Sun Jun 7 07:20:36 2020 From: chgans at gmail.com (Christian Gagneraud) Date: Sun, 7 Jun 2020 17:20:36 +1200 Subject: [Qbs] Evaluation of Conditional Depends In-Reply-To: <00D085B2-1213-46EA-A8B2-757B86F7860A@gudrian.org> References: <00D085B2-1213-46EA-A8B2-757B86F7860A@gudrian.org> Message-ID: On Sun, 7 Jun 2020 at 04:30, Christian Gudrian wrote: > > Hello! > > In ModuleA there is a property enableFeature which by default is false. > > ModuleB conditionally depends on ModuleC, if ModuleA.enableFeature is true. > > A Product depends on ModuleA and ModuleB and sets ModuleA.enableFeature to true. However, ModuleC is not used as a dependency. That looks like a weird scenario, maybe this means that the enableFeature property is not in the right place. Can't you move it to the top project, and pull it in Module A & B? Or maybe proxy the property in module B, e.g. your product assigns the same value to ModuleA.enableFeature and ModuleB.enableSameFeature? Chris From qbs at gudrian.org Sun Jun 7 10:49:41 2020 From: qbs at gudrian.org (Christian Gudrian) Date: Sun, 7 Jun 2020 10:49:41 +0200 Subject: [Qbs] Evaluation of Conditional Depends In-Reply-To: <36286d76-f59d-3c8e-988e-2ac490421e58@weickelt.de> References: <00D085B2-1213-46EA-A8B2-757B86F7860A@gudrian.org> <36286d76-f59d-3c8e-988e-2ac490421e58@weickelt.de> Message-ID: Hello! > Could you clarify the relationship between ModuleA and ModuleB? Maybe post > some minimal example code. I’ve put a simple example project on GitHub: https://github.com/cgudrian/QbsConfigurationDemo . I am trying to implement basic Qbs support for the RT operating system ChibiOS (https://www.chibios.org ). It supports a wide range of hardware platforms and peripheral components and is highly configurable. The OS is statically linked into the finally binary. Specific Hardware support can be enabled and disabled at will. The example code I have published tries to mimic the original source code layout and „supports“ two types of peripheral components: ADC and CAN. Each peripheral component consists of a generic, abstract part in the OS and a corresponding (low level) driver implementation which might come in different versions depending on the specific board the build is targeting. What I would like to end up with is the following: RTOSApplication { RTOS.enableADC: true Depends { name: "boards.Board1“ } file: "main.c" } Qbs has to - include the needed source files both for the OS and the driver - set the appropriate compiler defines - set the appropriate include paths Currently the board modules depend on the concrete drivers modules conditionally. By using this design the list properties (sourceFiles, defines, includePaths) automatically get appended to instead of replaced. And it is exactly these conditional dependencies that do not work. The modules A, B and C from my original post map to the modules in my example as follows: ModuleA -> RTOS ModuleB -> board.Board1, board.Board2 ModuleC -> driver.adc.v1, driver.adc.v2, driver.can.v1 Thanks! Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: From abbapoh at gmail.com Sun Jun 7 10:51:18 2020 From: abbapoh at gmail.com (=?utf-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Sun, 7 Jun 2020 10:51:18 +0200 Subject: [Qbs] building android aab package help In-Reply-To: References: <20200415094748.377a98b0@ckandeler-archlinux> <20200417091408.39901463@ckandeler-archlinux> Message-ID: <1DEF10E1-CEA1-48B6-BE33-6189AE48E984@gmail.com> Hello, Raphael! I’ve seen your new patch and it looks really interesting. So, for now, you have 2 separate patches for the AAB support, right? [0] https://codereview.qt-project.org/c/qbs/qbs/+/303358 [1] https://codereview.qt-project.org/c/qbs/qbs/+/289726 The multiplexing over type seems to be a very useful feature, but I’m afraid it’s not that easy to implement. I find it useful to multiplex a library over "staticlibrary"/"dynamiclibrary" types, but how do I link to such a multiplexed library? I am not sure it’s the simplest way to go. I would like to suggest similar solution which would not require (at least, for now) radically changing the way how multiplexing works. Could you please try this approach: 1. Introduce "property string packageType" with 2 (3 values?) - «apk», «aab», (undefined?) in the sdk module and make rules dependent on that. Undefined could be used for console applications (see below). 2. Change the type of the Android product from «android.apk» to «android.package» (or even simply use «application» if possible) 3. Set the new property in the Application.qbs by default, e.g. to preserve the old behavior, you can do like this: NativeBinary { type: isForAndroid && !consoleApplication ? «Android.package» : «application» // could it be simply «application»? sdk.packageType: !consoleApplication ? «apk» : undefined } Now, you want to build both apk and aab in one go. You can use multiplexing over profiles: Application { Profile { name: «a» sdk.packageType: «apk» baseProfile: project.profile } Profile { name: «b» sdk.packageType: «aab» baseProfile: project.profile } qbs.profiles: [«a», «b»] } Will that work? If no, would it be possible to make it working? Note that this is pseudo code, feel free to change the details. Ivan. > 17 апр. 2020 г., в 13:03, Raphael Cotty написал(а): > > The android tool aapt2 manages resources. Some output files required for the aab package need to be in the protobuf format. Also the R.java generated by aap2 is different from apk to aab. > That's what I meant by context. > The aab package doesn't need the apk package to be built. > > Because both packages need exactly the same input and because some of the rules are the same (java ones, dex one) I think it makes sense to build both packages by the same product. -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at weickelt.de Sun Jun 7 11:48:24 2020 From: richard at weickelt.de (Richard Weickelt) Date: Sun, 7 Jun 2020 11:48:24 +0200 (CEST) Subject: [Qbs] Evaluation of Conditional Depends In-Reply-To: References: <00D085B2-1213-46EA-A8B2-757B86F7860A@gudrian.org> <36286d76-f59d-3c8e-988e-2ac490421e58@weickelt.de> Message-ID: <20200607094824.5F3DE300729@dd18702.kasserver.com> Christian Gudrian wrote on 7. June 2020 10:48 (GMT +02:00): > > I’ve put a simple example project on GitHub: > https://github.com/cgudrian/QbsConfigurationDemo > . > > I am trying to implement basic Qbs support for the RT operating system > ChibiOS (https://www.chibios.org ). It supports > a wide range of hardware platforms and peripheral components and is highly > configurable. The OS is statically linked into the finally binary. > Specific Hardware support can be enabled and disabled at will. > > The example code I have published tries to mimic the original source code > layout and „supports“ two types of peripheral components: ADC and CAN. > Each peripheral component consists of a generic, abstract part in the OS > and a corresponding (low level) driver implementation which might come in > different versions depending on the specific board the build is targeting. > > What I would like to end up with is the following: > > RTOSApplication { > RTOS.enableADC: true > Depends { name: "boards.Board1“ } > file: "main.c" > } > > Qbs has to > - include the needed source files both for the OS and the driver > - set the appropriate compiler defines > - set the appropriate include paths > > Currently the board modules depend on the concrete drivers modules > conditionally. By using this design the list properties (sourceFiles, > defines, includePaths) automatically get appended to instead of replaced. > And it is exactly these conditional dependencies that do not work. > > The modules A, B and C from my original post map to the modules in my > example as follows: > > ModuleA -> RTOS > ModuleB -> board.Board1, board.Board2 > ModuleC -> driver.adc.v1, driver.adc.v2, driver.can.v1 You are setting values of the RTOS Module in the product. But I think module values from there do not populate when loading other modules unless you set them in the module itself (set Rtos.enableAdc in the board module). You may either: 1. Make enableAdc & friends a property of RtosApplication and use product.enableAdc in the conditional Depends item because product properties do populate. 2. Make enableAdc a property of the board module and set this one in your application. Something you might not be aware of: Qbs can handle multiple module variants in the same folder. You need to add a expression in the modules' condition that evaluates to true only for one module variant. That is how the cpp module does it with toolchainType. The variants could even be located in different locations in the fs as long as the folder structure is the same and all module subtrees are in qbsSearchPaths. That way you could have a single board module with x variants and a single ADC driver module with different versions in separate files. You would then set for instance board.type in your application and the board module would set add.version. You may use inheritance for sharing property definitions. This is not so obvious, thus study the cpp module. I think this would simplify your module structure a lot. Richard From raphael.cotty at gmail.com Sun Jun 7 14:18:46 2020 From: raphael.cotty at gmail.com (Raphael Cotty) Date: Sun, 7 Jun 2020 14:18:46 +0200 Subject: [Qbs] building android aab package help In-Reply-To: <1DEF10E1-CEA1-48B6-BE33-6189AE48E984@gmail.com> References: <20200415094748.377a98b0@ckandeler-archlinux> <20200417091408.39901463@ckandeler-archlinux> <1DEF10E1-CEA1-48B6-BE33-6189AE48E984@gmail.com> Message-ID: Hi, Looking into that... So I have a simple example like that: Application { Profile { name: "a" baseProfile: project.profile } Profile { name: "b" baseProfile: project.profile } qbs.profiles: ["a", "b"] files: [ "main.cpp" ] } I get this error: Result of expression 'qbs.targetOS' [undefined] is not an object. In NativeBinary.qbs Am I missing something here? The targetOS property is not set when the Profile appears in the Product? Thanks Raph Le dim. 7 juin 2020 à 10:51, Иван Комиссаров a écrit : > Hello, Raphael! > > I’ve seen your new patch and it looks really interesting. > > So, for now, you have 2 separate patches for the AAB support, right? > [0] https://codereview.qt-project.org/c/qbs/qbs/+/303358 > [1] https://codereview.qt-project.org/c/qbs/qbs/+/289726 > > The multiplexing over type seems to be a very useful feature, but I’m > afraid it’s not that easy to implement. I find it useful to multiplex a > library over "staticlibrary"/"dynamiclibrary" types, but how do I link to > such a multiplexed library? I am not sure it’s the simplest way to go. > > I would like to suggest similar solution which would not require (at > least, for now) radically changing the way how multiplexing works. > Could you please try this approach: > 1. Introduce "property string packageType" with 2 (3 values?) - «apk», > «aab», (undefined?) in the sdk module and make rules dependent on that. > Undefined could be used for console applications (see below). > 2. Change the type of the Android product from «android.apk» to > «android.package» (or even simply use «application» if possible) > 3. Set the new property in the Application.qbs by default, e.g. to > preserve the old behavior, you can do like this: > NativeBinary { > type: isForAndroid && !consoleApplication ? «Android.package» : > «application» // could it be simply «application»? > sdk.packageType: !consoleApplication ? «apk» : undefined > } > > Now, you want to build both apk and aab in one go. You can use > multiplexing over profiles: > > Application { > Profile { > name: «a» > sdk.packageType: «apk» > baseProfile: project.profile > } > Profile { > name: «b» > sdk.packageType: «aab» > baseProfile: project.profile > } > qbs.profiles: [«a», «b»] > } > > Will that work? If no, would it be possible to make it working? > Note that this is pseudo code, feel free to change the details. > > Ivan. > > 17 апр. 2020 г., в 13:03, Raphael Cotty > написал(а): > > The android tool aapt2 manages resources. Some output files required for > the aab package need to be in the protobuf format. Also the R.java > generated by aap2 is different from apk to aab. > That's what I meant by context. > The aab package doesn't need the apk package to be built. > > Because both packages need exactly the same input and because some of the > rules are the same (java ones, dex one) I think it makes sense to build > both packages by the same product. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abbapoh at gmail.com Sun Jun 7 15:41:32 2020 From: abbapoh at gmail.com (=?utf-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Sun, 7 Jun 2020 15:41:32 +0200 Subject: [Qbs] building android aab package help In-Reply-To: References: <20200415094748.377a98b0@ckandeler-archlinux> <20200417091408.39901463@ckandeler-archlinux> <1DEF10E1-CEA1-48B6-BE33-6189AE48E984@gmail.com> Message-ID: <930034D7-D619-4FBB-B8A6-89B379C81852@gmail.com> Interesting, I do not get that error. Maybe Christian knows better why this could happen? The following example works for me on Mac: CppApplication { name: qbs.profile consoleApplication: true Profile { name: "a" baseProfile: project.profile cpp.defines: 'MAGIC_MACRO="a"' } Profile { name: "b" baseProfile: project.profile cpp.defines: 'MAGIC_MACRO="b"' } qbs.profiles: ["a", "b"] files: [ "main.cpp" ] install: true installDir: "bin" } Note, that I had to change the product name, otherwise I get a conflict - there are 2 artifacts with the same name which are built to the same location (which is reasonable, but should not be your case). Also, I have to set consoleApplication to ‘true' since there’s a bug macOS bundle module - the product is not linked at all when trying to multiplex profiles. Should not be a problem in your case either. The bottom line is that I get 2 binaries, a and b each getting it’s own defines. Ivan > 7 июня 2020 г., в 14:18, Raphael Cotty написал(а): > > Hi, > Looking into that... > > So I have a simple example like that: > Application { > Profile { > name: "a" > baseProfile: project.profile > } > Profile { > name: "b" > baseProfile: project.profile > } > qbs.profiles: ["a", "b"] > files: [ "main.cpp" > ] > } > I get this error: Result of expression 'qbs.targetOS' [undefined] is not an object. In NativeBinary.qbs > > Am I missing something here? The targetOS property is not set when the Profile appears in the Product? > Thanks > Raph > > > Le dim. 7 juin 2020 à 10:51, Иван Комиссаров > a écrit : > Hello, Raphael! > > I’ve seen your new patch and it looks really interesting. > > So, for now, you have 2 separate patches for the AAB support, right? > [0] https://codereview.qt-project.org/c/qbs/qbs/+/303358 > [1] https://codereview.qt-project.org/c/qbs/qbs/+/289726 > > The multiplexing over type seems to be a very useful feature, but I’m afraid it’s not that easy to implement. I find it useful to multiplex a library over "staticlibrary"/"dynamiclibrary" types, but how do I link to such a multiplexed library? I am not sure it’s the simplest way to go. > > I would like to suggest similar solution which would not require (at least, for now) radically changing the way how multiplexing works. > Could you please try this approach: > 1. Introduce "property string packageType" with 2 (3 values?) - «apk», «aab», (undefined?) in the sdk module and make rules dependent on that. Undefined could be used for console applications (see below). > 2. Change the type of the Android product from «android.apk» to «android.package» (or even simply use «application» if possible) > 3. Set the new property in the Application.qbs by default, e.g. to preserve the old behavior, you can do like this: > NativeBinary { > type: isForAndroid && !consoleApplication ? «Android.package» : «application» // could it be simply «application»? > sdk.packageType: !consoleApplication ? «apk» : undefined > } > > Now, you want to build both apk and aab in one go. You can use multiplexing over profiles: > > Application { > Profile { > name: «a» > sdk.packageType: «apk» > baseProfile: project.profile > } > Profile { > name: «b» > sdk.packageType: «aab» > baseProfile: project.profile > } > qbs.profiles: [«a», «b»] > } > > Will that work? If no, would it be possible to make it working? > Note that this is pseudo code, feel free to change the details. > > Ivan. > >> 17 апр. 2020 г., в 13:03, Raphael Cotty > написал(а): >> >> The android tool aapt2 manages resources. Some output files required for the aab package need to be in the protobuf format. Also the R.java generated by aap2 is different from apk to aab. >> That's what I meant by context. >> The aab package doesn't need the apk package to be built. >> >> Because both packages need exactly the same input and because some of the rules are the same (java ones, dex one) I think it makes sense to build both packages by the same product. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raphael.cotty at gmail.com Sun Jun 7 20:30:53 2020 From: raphael.cotty at gmail.com (Raphael Cotty) Date: Sun, 7 Jun 2020 20:30:53 +0200 Subject: [Qbs] building android aab package help In-Reply-To: <930034D7-D619-4FBB-B8A6-89B379C81852@gmail.com> References: <20200415094748.377a98b0@ckandeler-archlinux> <20200417091408.39901463@ckandeler-archlinux> <1DEF10E1-CEA1-48B6-BE33-6189AE48E984@gmail.com> <930034D7-D619-4FBB-B8A6-89B379C81852@gmail.com> Message-ID: Hi, The build of the package (apk or aab) is done in the aggregate. So adding a profile can only impact the multiplexed targets. The multiplex targets are built the same way for apk and aab. It's the packaging (in the aggregate) that differs. Hence the multiplexing of the aggregate in my patch... Raph Le dim. 7 juin 2020 à 15:41, Иван Комиссаров a écrit : > Interesting, I do not get that error. Maybe Christian knows better why > this could happen? > > The following example works for me on Mac: > > CppApplication { > > name: qbs.profile > > consoleApplication: true > > Profile { > > name: "a" > > baseProfile: project.profile > > cpp.defines: 'MAGIC_MACRO="a"' > > } > > Profile { > > name: "b" > > baseProfile: project.profile > > cpp.defines: 'MAGIC_MACRO="b"' > > } > > qbs.profiles: ["a", "b"] > > files: [ "main.cpp" ] > > install: true > > installDir: "bin" > > } > > > Note, that I had to change the product name, otherwise I get a conflict - > there are 2 artifacts with the same name which are built to the same > location (which is reasonable, but should not be your case). > Also, I have to set consoleApplication to ‘true' since there’s a bug macOS > bundle module - the product is not linked at all when trying to multiplex > profiles. Should not be a problem in your case either. > The bottom line is that I get 2 binaries, a and b each getting it’s own > defines. > > Ivan > > 7 июня 2020 г., в 14:18, Raphael Cotty > написал(а): > > Hi, > Looking into that... > > So I have a simple example like that: > Application { > Profile { > name: "a" > baseProfile: project.profile > } > Profile { > name: "b" > baseProfile: project.profile > } > qbs.profiles: ["a", "b"] > files: [ "main.cpp" > ] > } > I get this error: Result of expression 'qbs.targetOS' [undefined] is not > an object. In NativeBinary.qbs > > Am I missing something here? The targetOS property is not set when the > Profile appears in the Product? > Thanks > Raph > > > Le dim. 7 juin 2020 à 10:51, Иван Комиссаров a écrit : > >> Hello, Raphael! >> >> I’ve seen your new patch and it looks really interesting. >> >> So, for now, you have 2 separate patches for the AAB support, right? >> [0] https://codereview.qt-project.org/c/qbs/qbs/+/303358 >> [1] https://codereview.qt-project.org/c/qbs/qbs/+/289726 >> >> The multiplexing over type seems to be a very useful feature, but I’m >> afraid it’s not that easy to implement. I find it useful to multiplex a >> library over "staticlibrary"/"dynamiclibrary" types, but how do I link to >> such a multiplexed library? I am not sure it’s the simplest way to go. >> >> I would like to suggest similar solution which would not require (at >> least, for now) radically changing the way how multiplexing works. >> Could you please try this approach: >> 1. Introduce "property string packageType" with 2 (3 values?) - «apk», >> «aab», (undefined?) in the sdk module and make rules dependent on that. >> Undefined could be used for console applications (see below). >> 2. Change the type of the Android product from «android.apk» to >> «android.package» (or even simply use «application» if possible) >> 3. Set the new property in the Application.qbs by default, e.g. to >> preserve the old behavior, you can do like this: >> NativeBinary { >> type: isForAndroid && !consoleApplication ? «Android.package» : >> «application» // could it be simply «application»? >> sdk.packageType: !consoleApplication ? «apk» : undefined >> } >> >> Now, you want to build both apk and aab in one go. You can use >> multiplexing over profiles: >> >> Application { >> Profile { >> name: «a» >> sdk.packageType: «apk» >> baseProfile: project.profile >> } >> Profile { >> name: «b» >> sdk.packageType: «aab» >> baseProfile: project.profile >> } >> qbs.profiles: [«a», «b»] >> } >> >> Will that work? If no, would it be possible to make it working? >> Note that this is pseudo code, feel free to change the details. >> >> Ivan. >> >> 17 апр. 2020 г., в 13:03, Raphael Cotty >> написал(а): >> >> The android tool aapt2 manages resources. Some output files required for >> the aab package need to be in the protobuf format. Also the R.java >> generated by aap2 is different from apk to aab. >> That's what I meant by context. >> The aab package doesn't need the apk package to be built. >> >> Because both packages need exactly the same input and because some of the >> rules are the same (java ones, dex one) I think it makes sense to build >> both packages by the same product. >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From qbs at gudrian.org Tue Jun 9 20:55:43 2020 From: qbs at gudrian.org (Christian Gudrian) Date: Tue, 9 Jun 2020 20:55:43 +0200 Subject: [Qbs] Evaluation of Conditional Depends In-Reply-To: <20200607094824.5F3DE300729@dd18702.kasserver.com> References: <00D085B2-1213-46EA-A8B2-757B86F7860A@gudrian.org> <36286d76-f59d-3c8e-988e-2ac490421e58@weickelt.de> <20200607094824.5F3DE300729@dd18702.kasserver.com> Message-ID: <69A2DEA0-87DC-4D1E-9873-418FF05BACA8@gudrian.org> Hello, again! Richard Weickelt wrote: > You need to add a expression in the modules' condition that evaluates to true only for one module variant. Could it be that only a restricted set of variables is available during evaluation of the module’s „condition“ property? Neither „product“ nor any imported modules’ variables can be accessed („Can’t find variable“ error). Is that a known limitation or am I doing something wrong? Christian From christian.kandeler at qt.io Wed Jun 10 10:09:02 2020 From: christian.kandeler at qt.io (Christian Kandeler) Date: Wed, 10 Jun 2020 10:09:02 +0200 Subject: [Qbs] Evaluation of Conditional Depends In-Reply-To: <69A2DEA0-87DC-4D1E-9873-418FF05BACA8@gudrian.org> References: <00D085B2-1213-46EA-A8B2-757B86F7860A@gudrian.org> <36286d76-f59d-3c8e-988e-2ac490421e58@weickelt.de> <20200607094824.5F3DE300729@dd18702.kasserver.com> <69A2DEA0-87DC-4D1E-9873-418FF05BACA8@gudrian.org> Message-ID: <20200610100902.095e9e6e@ckandeler-archlinux> On Tue, 9 Jun 2020 20:55:43 +0200 Christian Gudrian wrote: > Could it be that only a restricted set of variables is available during evaluation of the module’s „condition“ property? Neither „product“ nor any imported modules’ variables can be accessed („Can’t find variable“ error). > > Is that a known limitation or am I doing something wrong? Remember that the module has not been loaded yet, so the right-hand side of the condition property is rather restricted in terms of what you can access there. Basically, it's just the qbs module. Christian From richard at weickelt.de Wed Jun 10 10:33:59 2020 From: richard at weickelt.de (Richard Weickelt) Date: Wed, 10 Jun 2020 10:33:59 +0200 (CEST) Subject: [Qbs] Evaluation of Conditional Depends In-Reply-To: <20200610100902.095e9e6e@ckandeler-archlinux> References: <00D085B2-1213-46EA-A8B2-757B86F7860A@gudrian.org> <36286d76-f59d-3c8e-988e-2ac490421e58@weickelt.de> <20200607094824.5F3DE300729@dd18702.kasserver.com> <69A2DEA0-87DC-4D1E-9873-418FF05BACA8@gudrian.org><20200610100902.095e9e6e@ckandeler-archlinux> Message-ID: <20200610083359.79CB730042E@dd18702.kasserver.com> Christian Kandeler wrote on 10. June 2020 10:09 (GMT +02:00): > On Tue, 9 Jun 2020 20:55:43 +0200 > Christian Gudrian wrote: > >> Could it be that only a restricted set of variables is available during >> evaluation of the module’s „condition“ property? Neither >> „product“ nor any imported modules’ variables can be accessed >> („Can’t find variable“ error). >> >> Is that a known limitation or am I doing something wrong? > > Remember that the module has not been loaded yet, so the right-hand side > of the condition property is rather restricted in terms of what you can > access there. Basically, it's just the qbs module. And of course the module's own properties set in the module file, except those referring to probes. But we do evaluate the module condition in a product context. Is that not the real product context or at least very close? E.g. if product sets moduleX.propA to true and depends on moduleX, is propA then not true when evaluating the condition? At least that was my expectation in my previous reply. Also, doesn't it make sense to provide access to custom product properties in that phase? From richard at weickelt.de Wed Jun 10 11:37:02 2020 From: richard at weickelt.de (Richard Weickelt) Date: Wed, 10 Jun 2020 11:37:02 +0200 (CEST) Subject: [Qbs] Evaluation of Conditional Depends In-Reply-To: <20200610083359.79CB730042E@dd18702.kasserver.com> References: <00D085B2-1213-46EA-A8B2-757B86F7860A@gudrian.org> <36286d76-f59d-3c8e-988e-2ac490421e58@weickelt.de> <20200607094824.5F3DE300729@dd18702.kasserver.com> <69A2DEA0-87DC-4D1E-9873-418FF05BACA8@gudrian.org><20200610100902.095e9e6e@ckandeler-archlinux><20200610083359.79CB730042E@dd18702.kasserver.com> Message-ID: <20200610093702.68EC5300430@dd18702.kasserver.com> > And of course the module's own properties set in the module file, except > those referring to probes. But we do evaluate the module condition in a > product context. Is that not the real product context or at least very > close? E.g. if product sets moduleX.propA to true and depends on moduleX, > is propA then not true when evaluating the condition? At least that was my > expectation in my previous reply. Also, doesn't it make sense to provide > access to custom product properties in that phase? ... And module properties set in the profile. I had a glance look at the source code. When evaluating the condition property, we are taking the following information from the product context into account: - module values set in the profile (can even be a local profile within the product item) - a fully(?) resolved instance of the qbs module The result is then cached since this module might be loaded multiple times in the same product context. I don't see why we could not allow access to product as well as project properties and module properties set in the product item. Christian, is that restriction by purpose? From christian.kandeler at qt.io Wed Jun 10 12:32:40 2020 From: christian.kandeler at qt.io (Christian Kandeler) Date: Wed, 10 Jun 2020 12:32:40 +0200 Subject: [Qbs] Evaluation of Conditional Depends In-Reply-To: <20200610093702.68EC5300430@dd18702.kasserver.com> References: <00D085B2-1213-46EA-A8B2-757B86F7860A@gudrian.org> <36286d76-f59d-3c8e-988e-2ac490421e58@weickelt.de> <20200607094824.5F3DE300729@dd18702.kasserver.com> <69A2DEA0-87DC-4D1E-9873-418FF05BACA8@gudrian.org> <20200610100902.095e9e6e@ckandeler-archlinux> <20200610083359.79CB730042E@dd18702.kasserver.com> <20200610093702.68EC5300430@dd18702.kasserver.com> Message-ID: <20200610123240.7c8e2a0e@ckandeler-archlinux> On Wed, 10 Jun 2020 11:37:02 +0200 (CEST) "Richard Weickelt" wrote: > ... And module properties set in the profile. I had a glance look at the source code. When evaluating the condition property, we are taking the following information from the product context into account: > > - module values set in the profile (can even be a local profile within the product item) > - a fully(?) resolved instance of the qbs module > > The result is then cached since this module might be loaded multiple times in the same product context. I don't see why we could not allow access to product as well as project properties and module properties set in the product item. > > Christian, is that restriction by purpose? Well, there was no use case so far, and it does seem a bit dubious at first glance. But if there's a compelling case, perhaps it could be added (if it is actually possible; it's been a while since I've done work in that area). Christian From qt-maillist at hazardy.de Fri Jun 26 13:14:11 2020 From: qt-maillist at hazardy.de (=?UTF-8?Q?Bj=c3=b6rn_Sch=c3=a4pers?=) Date: Fri, 26 Jun 2020 13:14:11 +0200 Subject: [Qbs] Products with Space in Name Message-ID: <59c44cd7-127d-6c9d-c830-5417e9bf2255@hazardy.de> Hi, I have a lot of products which have spaces in their name. Until now everything was fine, but now I want to access the property of one of my dependencies. How to do that with a space in the name, or should spaces in the name be banned completely? Works: DynamicLibrary { name: "FooBar" } CppApplication { Depends { name: "cpp" } Depends { name: "FooBar" } cpp.defines = ["FOO_PATH=\"" + FooBar.buildDirectory + "\""] } Does not work: DynamicLibrary { name: "Foo Bar" } CppApplication { Depends { name: "cpp" } Depends { name: "Foo Bar" } cpp.defines = ["FOO_PATH=\"" + (What to put here?).buildDirectory + "\""] } If you wonder what I'm trying to do: Write a plugin (loader) and test it. For that I need the path where my plugin is located. If there is a better way to do that I'm all ears. Kind regards, Björn. From christian.kandeler at qt.io Fri Jun 26 13:42:27 2020 From: christian.kandeler at qt.io (Christian Kandeler) Date: Fri, 26 Jun 2020 13:42:27 +0200 Subject: [Qbs] Products with Space in Name In-Reply-To: <59c44cd7-127d-6c9d-c830-5417e9bf2255@hazardy.de> References: <59c44cd7-127d-6c9d-c830-5417e9bf2255@hazardy.de> Message-ID: <20200626134227.482b0667@ckandeler-archlinux> On Fri, 26 Jun 2020 13:14:11 +0200 Björn Schäpers wrote: > DynamicLibrary { > name: "FooBar" > } > > CppApplication { > Depends { name: "cpp" } > Depends { name: "FooBar" } > cpp.defines = ["FOO_PATH=\"" + FooBar.buildDirectory + "\""] Eww... This works? You cannot rely on that, these properties are conceptually private. Please use exports instead: DynamicLibrary { name: "FooBar" Export { property string theDir: product.buildDirectory } } CppApplication { Depends { name: "cpp" } Depends { name: "FooBar" } cpp.defines = ["FOO_PATH=\"" + FooBar.theDir + "\""] } > Does not work: > DynamicLibrary { > name: "Foo Bar" > } > > CppApplication { > Depends { name: "cpp" } > Depends { name: "Foo Bar" } Depends { name: "Foo Bar"; id: foobar } cpp.defines = ["FOO_PATH=\"" + foobar.buildDirectory + "\""] Christian From qt-maillist at hazardy.de Fri Jun 26 13:47:57 2020 From: qt-maillist at hazardy.de (=?UTF-8?Q?Bj=c3=b6rn_Sch=c3=a4pers?=) Date: Fri, 26 Jun 2020 13:47:57 +0200 Subject: [Qbs] Products with Space in Name In-Reply-To: <20200626134227.482b0667@ckandeler-archlinux> References: <59c44cd7-127d-6c9d-c830-5417e9bf2255@hazardy.de> <20200626134227.482b0667@ckandeler-archlinux> Message-ID: Am 26.06.2020 um 13:42 schrieb Christian Kandeler: > On Fri, 26 Jun 2020 13:14:11 +0200 > Björn Schäpers wrote: > >> DynamicLibrary { >> name: "FooBar" >> } >> >> CppApplication { >> Depends { name: "cpp" } >> Depends { name: "FooBar" } >> cpp.defines = ["FOO_PATH=\"" + FooBar.buildDirectory + "\""] > Eww... This works? You cannot rely on that, these properties are conceptually private. Please use exports instead: Yeah just realized it does not work, before that I only tested with product.buildDirectory. > > DynamicLibrary { > name: "FooBar" > Export { property string theDir: product.buildDirectory } > } > > CppApplication { > Depends { name: "cpp" } > Depends { name: "FooBar" } > cpp.defines = ["FOO_PATH=\"" + FooBar.theDir + "\""] > } > >> Does not work: >> DynamicLibrary { >> name: "Foo Bar" >> } >> >> CppApplication { >> Depends { name: "cpp" } >> Depends { name: "Foo Bar" } > Depends { name: "Foo Bar"; id: foobar } > cpp.defines = ["FOO_PATH=\"" + foobar.buildDirectory + "\""] > > > Christian Thanks, Björn. From hkarel at yandex.ru Tue Jun 30 09:45:10 2020 From: hkarel at yandex.ru (=?UTF-8?B?0JrQsNGA0LXQu9C40L0g0J/QsNCy0LXQuw==?=) Date: Tue, 30 Jun 2020 10:45:10 +0300 Subject: [Qbs] QBS script parsing speed Message-ID: <6ae25015-f8a3-1ab4-2769-845ee7cd0e29@yandex.ru> Hello. Now I'm trying to write a QBS build script for a fairly large project (QGIS). After making every change to the build script - the project tree is rebuilt and QtCreator freezes for 10-15 seconds. It seems that 10-15 is not so much, but since I have to make a lot of changes in the script, in the aggregate the slowdown turns out to be quite significant. I suppose I was not the only one who faced a similar problem on large projects. I would like to know if any measures are being planned to increase the speed of re-parsing a project? I am using QtCreator 4.11.2 (QBS 1.15.1) -- BR, Pavel Karelin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jochen.ulrich at clausmark.com Tue Jun 30 10:24:51 2020 From: jochen.ulrich at clausmark.com (Jochen Ulrich) Date: Tue, 30 Jun 2020 08:24:51 +0000 Subject: [Qbs] QBS script parsing speed In-Reply-To: <6ae25015-f8a3-1ab4-2769-845ee7cd0e29@yandex.ru> References: <6ae25015-f8a3-1ab4-2769-845ee7cd0e29@yandex.ru> Message-ID: <7B127AE2-5E16-40C9-ADE4-E0076BB07BF6@clausmark.com> We faced similar problems but our resolve times were even higher (30 s to 2 mins). We were able to work around this and significantly reduce the resolve times by avoiding transitive dependencies (meaning exporting dependencies). So instead of this: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Product { name: “A” Depends { name: "B" } } Product { name: “B” Depends { name: "C" } Export { Depends { name: "C" } } } Product { name: “C” Depends { name: "SomeLibNeededEverywhere" } Export { Depends { name: "SomeLibNeededEverywhere" } } } <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< You do it like this >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Product { name: “A” Depends { name: "B" } Depends { name: "C" } Depends { name: "SomeLibNeededEverywhere" } } Product { name: “B” Depends { name: "C" } Depends { name: "SomeLibNeededEverywhere" } } Product { name: “C” Depends { name: "SomeLibNeededEverywhere" } } <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Of course it is ugly because you have to maintain the transitive dependencies manually. However, if you have cases where a dependency is needed in many places, you can create custom products that include it. For example: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> // qbs/imports/MyBaseApplication.qbs CppApplication { Depends { name: "SomeLibNeededEverywhere" } } // in other .qbs files use MyBaseApplication instead of CppApplication MyBaseApplication { } <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< See also this thread on the mailing list: https://lists.qt-project.org/pipermail/qbs/2019-July/002477.html and the follow up: https://lists.qt-project.org/pipermail/qbs/2019-August/002544.html Kind regards Jochen Ulrich > Von: Qbs im Auftrag von Карелин Павел > Datum: Dienstag, 30. Juni 2020 um 09:45 > An: "qbs at qt-project.org" > Betreff: [Qbs] QBS script parsing speed > > Hello. > > Now I'm trying to write a QBS build script for a fairly large project (QGIS). After making every change to the build script - the project tree is rebuilt and QtCreator freezes for 10-15 seconds. > It seems that 10-15 is not so much, but since I have to make a lot of changes in the script, in the aggregate the slowdown turns out to be quite significant. > I suppose I was not the only one who faced a similar problem on large projects. I would like to know if any measures are being planned to increase the speed of re-parsing a project? > I am using QtCreator 4.11.2 (QBS 1.15.1) > > > -- > BR, Pavel Karelin From richard at weickelt.de Tue Jun 30 13:32:19 2020 From: richard at weickelt.de (Richard Weickelt) Date: Tue, 30 Jun 2020 13:32:19 +0200 Subject: [Qbs] QBS script parsing speed In-Reply-To: <7B127AE2-5E16-40C9-ADE4-E0076BB07BF6@clausmark.com> References: <6ae25015-f8a3-1ab4-2769-845ee7cd0e29@yandex.ru> <7B127AE2-5E16-40C9-ADE4-E0076BB07BF6@clausmark.com> Message-ID: <6fad6489-3f44-e563-512e-1a0b55475a8e@weickelt.de> > We faced similar problems but our resolve times were even higher (30 s to > 2 mins). > > We were able to work around this and significantly reduce the resolve > times by avoiding transitive dependencies (meaning exporting > dependencies). I would like to understand why exactly this pattern makes the evaluation time explode. From richard at weickelt.de Tue Jun 30 13:49:58 2020 From: richard at weickelt.de (Richard Weickelt) Date: Tue, 30 Jun 2020 13:49:58 +0200 Subject: [Qbs] QBS script parsing speed In-Reply-To: <6ae25015-f8a3-1ab4-2769-845ee7cd0e29@yandex.ru> References: <6ae25015-f8a3-1ab4-2769-845ee7cd0e29@yandex.ru> Message-ID: > I would like to know if any measures are being planned to > increase the speed of re-parsing a project? I am using QtCreator 4.11.2 > (QBS 1.15.1) Some ideas: 1. Incremental project resolving: Take the dependency graph into account when re-resolving a project so that unchanged products are not evaluated again. 2. Parallel resolving: Evaluate unrelated products using multiple threads. Both would require a lot of refactoring work in the projectresolver and moduleloader modules. I would really like to do something about it or see somebody else doing something about it. But as a spare time job, this looks undoable. Nevertheless, we can try our best to make small steps forward. Richard From jochen.ulrich at clausmark.com Tue Jun 30 13:56:36 2020 From: jochen.ulrich at clausmark.com (Jochen Ulrich) Date: Tue, 30 Jun 2020 11:56:36 +0000 Subject: [Qbs] QBS script parsing speed In-Reply-To: <6fad6489-3f44-e563-512e-1a0b55475a8e@weickelt.de> References: <6ae25015-f8a3-1ab4-2769-845ee7cd0e29@yandex.ru> <7B127AE2-5E16-40C9-ADE4-E0076BB07BF6@clausmark.com> <6fad6489-3f44-e563-512e-1a0b55475a8e@weickelt.de> Message-ID: <51326C89-5148-451D-A691-7F7F258AF67B@clausmark.com> My analysis back then was: > Well [the time] goes into "Handling Products". So it is ModuleLoader::handleProduct(). > And there, it could be the ModuleMerger. But speculation is dangerous when discussing about performance. See https://lists.qt-project.org/pipermail/qbs/2019-August/002546.html You can find my test results together with the scripts to generate the projects here: https://gist.github.com/j-ulrich/35f345007809c77403a8ee88f4d9db11#file-results-md Best Jochen From richard at weickelt.de Tue Jun 30 15:09:21 2020 From: richard at weickelt.de (Richard Weickelt) Date: Tue, 30 Jun 2020 15:09:21 +0200 Subject: [Qbs] QBS script parsing speed In-Reply-To: <51326C89-5148-451D-A691-7F7F258AF67B@clausmark.com> References: <6ae25015-f8a3-1ab4-2769-845ee7cd0e29@yandex.ru> <7B127AE2-5E16-40C9-ADE4-E0076BB07BF6@clausmark.com> <6fad6489-3f44-e563-512e-1a0b55475a8e@weickelt.de> <51326C89-5148-451D-A691-7F7F258AF67B@clausmark.com> Message-ID: <760bcf5e-1cb2-bda4-7215-c854b5aebb7f@weickelt.de> Jochen, >> Well [the time] goes into "Handling Products". So it is ModuleLoader::handleProduct(). >> And there, it could be the ModuleMerger. But speculation is dangerous when discussing about performance. > See https://lists.qt-project.org/pipermail/qbs/2019-August/002546.html > > You can find my test results together with the scripts to generate the projects here: > https://gist.github.com/j-ulrich/35f345007809c77403a8ee88f4d9db11#file-results-md Then you might be happy to hear that the ModuleMerger was completely rewritten for Qbs 1.16.0 (https://codereview.qt-project.org/c/qbs/qbs/+/284737). Running your benchmark with Qbs 1.16.0 (Qt Creator 4.12) gives me significantly better results in case of transitive dependencies. See below. I am not sure whether this has any noticable effect on real-world projects. But if ModuleMerger was ever a bottleneck, then it should not longer be. --------------------- i5-2520M CPU @ 2.50GHz Xubuntu 16.04) First line: Qbs 1.15.1 Second line: Qbs 1.16.0 > Resolving 4-8-direct real 0m3.089s real 0m2.669s > Resolving 4-8-implicit real 0m4.808s real 0m3.409s > Resolving 4-8-explicit real 0m3.898s real 0m3.085s > Resolving withLeafExports/4-8-direct real 0m16.508s real 0m13.793s > Resolving withLeafExports/4-8-implicit real 0m25.907s real 0m18.180s > Resolving withLeafExports/4-8-explicit real 0m21.393s real 0m15.844s > Resolving withLeafExports/9-2-direct real 0m13.992s real 0m10.750s > Resolving withLeafExports/9-2-implicit real 0m43.592s real 0m24.494s > Resolving withLeafExports/9-2-explicit real 0m26.019s real 0m17.589s > Resolving withAdditionalDepends/4-8-direct real 0m25.096s real 0m18.892s > Resolving withAdditionalDepends/4-8-implicit real 0m28.369s real 0m19.868s > Resolving withAdditionalDepends/4-8-explicit real 0m29.164s real 0m19.319s > Resolving withAdditionalDepends/9-2-direct real 0m19.110s real 0m17.264s > Resolving withAdditionalDepends/9-2-implicit real 0m20.887s real 0m19.269s > Resolving withAdditionalDepends/9-2-explicit real 0m18.359s real 0m18.149s > Resolving 9-2-direct real 0m2.500s > Resolving 9-2-implicit real 0m6.393s > Resolving 9-2-explicit real 0m3.833s real 0m2.326s From hkarel at yandex.ru Tue Jun 30 16:50:00 2020 From: hkarel at yandex.ru (=?UTF-8?B?0JrQsNGA0LXQu9C40L0g0J/QsNCy0LXQuw==?=) Date: Tue, 30 Jun 2020 17:50:00 +0300 Subject: [Qbs] QBS script parsing speed In-Reply-To: <7B127AE2-5E16-40C9-ADE4-E0076BB07BF6@clausmark.com> References: <6ae25015-f8a3-1ab4-2769-845ee7cd0e29@yandex.ru> <7B127AE2-5E16-40C9-ADE4-E0076BB07BF6@clausmark.com> Message-ID: <0204ae7a-71ab-e57d-d717-e7947f0c2794@yandex.ru> I already use the second variant. The maximum that I export this:     Export {         Depends { name: "cpp" }         cpp.includePaths: product.exportIncludePaths     } But to connect files, I use wildcard mask almost everywhere. In topic "Improving qbs resolve performance" (https://lists.qt-project.org/pipermail/qbs/2019-July/002481.html) Christian Kandeler does not recommend doing this. But now I can’t do it differently - there are a lots of files, and I can’t connect them all individually. -- BR, Pavel Karelin 30.06.2020 11:24, Jochen Ulrich пишет: > We faced similar problems but our resolve times were even higher (30 s to 2 mins). > > We were able to work around this and significantly reduce the resolve times by avoiding transitive dependencies (meaning exporting dependencies). > > So instead of this: > > Product { > name: “A” > Depends { name: "B" } > } > > Product { > name: “B” > Depends { name: "C" } > Export { > Depends { name: "C" } > } > } > > Product { > name: “C” > Depends { name: "SomeLibNeededEverywhere" } > Export { > Depends { name: "SomeLibNeededEverywhere" } > } > } > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > You do it like this > > Product { > name: “A” > Depends { name: "B" } > Depends { name: "C" } > Depends { name: "SomeLibNeededEverywhere" } > } > > Product { > name: “B” > Depends { name: "C" } > Depends { name: "SomeLibNeededEverywhere" } > } > > Product { > name: “C” > Depends { name: "SomeLibNeededEverywhere" } > } > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > Of course it is ugly because you have to maintain the transitive dependencies manually. > However, if you have cases where a dependency is needed in many places, you can create custom products that include it. > For example: > // qbs/imports/MyBaseApplication.qbs > CppApplication { > Depends { name: "SomeLibNeededEverywhere" } > } > > // in other .qbs files use MyBaseApplication instead of CppApplication > MyBaseApplication { > } > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > See also this thread on the mailing list: > https://lists.qt-project.org/pipermail/qbs/2019-July/002477.html > and the follow up: > https://lists.qt-project.org/pipermail/qbs/2019-August/002544.html > > Kind regards > Jochen Ulrich > >> Von: Qbs im Auftrag von Карелин Павел >> Datum: Dienstag, 30. Juni 2020 um 09:45 >> An: "qbs at qt-project.org" >> Betreff: [Qbs] QBS script parsing speed >> >> Hello. >> >> Now I'm trying to write a QBS build script for a fairly large project (QGIS). After making every change to the build script - the project tree is rebuilt and QtCreator freezes for 10-15 seconds. >> It seems that 10-15 is not so much, but since I have to make a lot of changes in the script, in the aggregate the slowdown turns out to be quite significant. >> I suppose I was not the only one who faced a similar problem on large projects. I would like to know if any measures are being planned to increase the speed of re-parsing a project? >> I am using QtCreator 4.11.2 (QBS 1.15.1) >> >> >> -- >> BR, Pavel Karelin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jochen.ulrich at clausmark.com Tue Jun 30 17:09:59 2020 From: jochen.ulrich at clausmark.com (Jochen Ulrich) Date: Tue, 30 Jun 2020 15:09:59 +0000 Subject: [Qbs] QBS script parsing speed In-Reply-To: <760bcf5e-1cb2-bda4-7215-c854b5aebb7f@weickelt.de> References: <6ae25015-f8a3-1ab4-2769-845ee7cd0e29@yandex.ru> <7B127AE2-5E16-40C9-ADE4-E0076BB07BF6@clausmark.com> <6fad6489-3f44-e563-512e-1a0b55475a8e@weickelt.de> <51326C89-5148-451D-A691-7F7F258AF67B@clausmark.com> <760bcf5e-1cb2-bda4-7215-c854b5aebb7f@weickelt.de> Message-ID: Nice! It brings a ~44% speed improvement in the problematic case according to your numbers: > Resolving withLeafExports/9-2-implicit real 0m43.592s real 0m24.494s Thanks, Richard! So for "medium" projects in terms of depth of the dependency tree, it's sensible to use transitive dependencies now: withLeafExports/4-8-implicit: real 0m18.180s vs. withAdditionalDepends/4-8-explicit: real 0m19.319s However, for "large" projects, the workaround still seems to be 25% faster: withLeafExports/9-2-implicit: real 0m24.494s vs. withAdditionalDepends/9-2-explicit: real 0m18.149s Best Jochen Am 30.06.20, 15:09 schrieb "Richard Weickelt" : Jochen, >> Well [the time] goes into "Handling Products". So it is ModuleLoader::handleProduct(). >> And there, it could be the ModuleMerger. But speculation is dangerous when discussing about performance. > See https://lists.qt-project.org/pipermail/qbs/2019-August/002546.html > > You can find my test results together with the scripts to generate the projects here: > https://gist.github.com/j-ulrich/35f345007809c77403a8ee88f4d9db11#file-results-md Then you might be happy to hear that the ModuleMerger was completely rewritten for Qbs 1.16.0 (https://codereview.qt-project.org/c/qbs/qbs/+/284737). Running your benchmark with Qbs 1.16.0 (Qt Creator 4.12) gives me significantly better results in case of transitive dependencies. See below. I am not sure whether this has any noticable effect on real-world projects. But if ModuleMerger was ever a bottleneck, then it should not longer be. --------------------- i5-2520M CPU @ 2.50GHz Xubuntu 16.04) First line: Qbs 1.15.1 Second line: Qbs 1.16.0 > Resolving 4-8-direct real 0m3.089s real 0m2.669s > Resolving 4-8-implicit real 0m4.808s real 0m3.409s > Resolving 4-8-explicit real 0m3.898s real 0m3.085s > Resolving withLeafExports/4-8-direct real 0m16.508s real 0m13.793s > Resolving withLeafExports/4-8-implicit real 0m25.907s real 0m18.180s > Resolving withLeafExports/4-8-explicit real 0m21.393s real 0m15.844s > Resolving withLeafExports/9-2-direct real 0m13.992s real 0m10.750s > Resolving withLeafExports/9-2-implicit real 0m43.592s real 0m24.494s > Resolving withLeafExports/9-2-explicit real 0m26.019s real 0m17.589s > Resolving withAdditionalDepends/4-8-direct real 0m25.096s real 0m18.892s > Resolving withAdditionalDepends/4-8-implicit real 0m28.369s real 0m19.868s > Resolving withAdditionalDepends/4-8-explicit real 0m29.164s real 0m19.319s > Resolving withAdditionalDepends/9-2-direct real 0m19.110s real 0m17.264s > Resolving withAdditionalDepends/9-2-implicit real 0m20.887s real 0m19.269s > Resolving withAdditionalDepends/9-2-explicit real 0m18.359s real 0m18.149s > Resolving 9-2-direct real 0m2.500s > Resolving 9-2-implicit real 0m6.393s > Resolving 9-2-explicit real 0m3.833s real 0m2.326s