[Qbs] building android aab package help

[Иван Комиссаров]

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 <raphael.cotty at gmail.com> написал(а):
> 
> 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, Иван Комиссаров <abbapoh at gmail.com <mailto:abbapoh at gmail.com>> 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 <https://codereview.qt-project.org/c/qbs/qbs/+/303358>
> [1] https://codereview.qt-project.org/c/qbs/qbs/+/289726 <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 <raphael.cotty at gmail.com <mailto:raphael.cotty at gmail.com>> написал(а):
>> 
>> 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: <http://lists.qt-project.org/pipermail/qbs/attachments/20200607/213f6beb/attachment-0001.html>