QBS: Explicitly setting qbs.profiles inside Products causing build to fail

My use-case is this:

I have a static library which I want to be available for some profiles (e.g. "gcc", "arm-gcc", "mips-gcc").

I also have an application which links to this library, but this applications should only build using a specific profile (e.g. "arm-gcc").

For this I am modifying the app-and-lib QBS example.

The lib.qbs file:

import qbs 1.0

Product {
    qbs.profiles: ["gcc", "arm-gcc", "mips-gcc"] //I added only this line
    type: "staticlibrary"
    name: "mylib"
    files: [
        "lib.cpp",
        "lib.h",
    ]
    Depends { name: 'cpp' }
    cpp.defines: ['CRUCIAL_DEFINE']

    Export {
        Depends { name: "cpp" }
        cpp.includePaths: [product.sourceDirectory]
    }
}

The app.qbs file:

import qbs 1.0

Product {
    qbs.profiles: ["arm-gcc"] //I added only this line
    type: "application"
    consoleApplication: true
    files : [ "main.cpp" ]
    Depends { name: "cpp" }
    Depends { name: "mylib" }
}

The app build fails. Qbs wrongly tries to link to the "gcc" version of the library instead of the "arm-gcc" version, as you can see in the log:

Build graph does not yet exist for configuration 'default'. Starting from scratch.
Resolving project for configuration default
Setting up build graph for configuration default
Building for configuration default
compiling lib.cpp [mylib {"profile":"gcc"}]
compiling lib.cpp [mylib {"profile":"arm-gcc"}]
compiling lib.cpp [mylib {"profile":"mips-gcc"}]
compiling main.cpp [app]
creating libmylib.a [mylib {"profile":"gcc"}]
creating libmylib.a [mylib {"profile":"mips-gcc"}]
creating libmylib.a [mylib {"profile":"arm-gcc"}]
linking app [app]
ERROR: /usr/bin/arm-linux-gnueabihf-g++ -o /home/user/programs/qbs/usr/local/share/qbs/examples/app-and-lib/default/app.7d104347/app /home/user/programs/qbs/usr/local/share/qbs/examples/app-and-lib/default/app.7d104347/3a52ce780950d4d9/main.cpp.o /home/user/programs/qbs/usr/local/share/qbs/examples/app-and-lib/default/mylib.eyJwcm9maWxlIjoiZ2NjIn0-.792f47ec/libmylib.a

ERROR: /home/user/programs/qbs/usr/local/share/qbs/examples/app-and-lib/default/mylib.eyJwcm9maWxlIjoiZ2NjIn0-.792f47ec/libmylib.a: error adding symbols: File format not recognized
collect2: error: ld returned 1 exit status
ERROR: Process failed with exit code 1.
The following products could not be built for configuration default:
app

The build fails only when selecting one profile in the app.qbs file, and this profile should not be the first profile in the qbs.profiles line in the lib.qbs file.

When selecting two or more profiles - the build succeeds.

My analysis:

I think this problem is related to multiplexing:

The lib.qbs contains more than one profile. This turns on multiplexing when building the library, which, in turn, adds additional 'multiplexConfigurationId' to the build-directory name (moduleloader.cpp).

The app.lib contains only one profile, so multiplexing is not turned on and the build-directory name does not get the extra string.

The problem can be solved by changing the code (moduleloader.cpp) so that multiplexing is turned even if there is only one profile i.e. with the following patch:

--- moduleloader.cpp    2018-10-24 16:17:43.633527397 +0300
+++ moduleloader.cpp.new    2018-10-24 16:18:27.541370544 +0300
@@ -872,7 +872,7 @@
             = callWithTemporaryBaseModule<const MultiplexInfo>(dummyContext,
                                                                extractMultiplexInfoFromProduct);

-    if (multiplexInfo.table.size() > 1)
+    if (multiplexInfo.table.size() > 0)
         productItem->setProperty(StringConstants::multiplexedProperty(), VariantValue::trueValue());

     VariantValuePtr productNameValue = VariantValue::create(productName);
@@ -891,7 +891,7 @@
         const QString multiplexConfigurationId = multiplexInfo.toIdString(row);
         const VariantValuePtr multiplexConfigurationIdValue
             = VariantValue::create(multiplexConfigurationId);
-        if (multiplexInfo.table.size() > 1 || aggregator) {
+        if (multiplexInfo.table.size() > 0 || aggregator) {
             multiplexConfigurationIdValues.push_back(multiplexConfigurationIdValue);
             item->setProperty(StringConstants::multiplexConfigurationIdProperty(),
                               multiplexConfigurationIdValue);

This worked for my use case. I don't know if it make sense in a broader view.

Finally, the questions:

Does it all make sense?

Is this a normal behavior?

Is this use-case simply not supported?

Is there a better solution?

Thanks in advance.

Yes, the default behavior with multiplexing is that the a non-multiplexed product depends on all variants of the dependency. In general, there is no way for a user to change that behavior, but there should be. However, luckily for you, profiles are special:

Depends { name: "mylib"; profiles: "arm-gcc" }

This should fix your problem.