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.co...@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, Иван Комиссаров <abba...@gmail.com
> <mailto:abba...@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.co...@gmail.com
>> <mailto:raphael.co...@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.
>
_______________________________________________
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
