Re: [Qbs] building android aab package help

[Raphael Cotty]

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.
>>
>>
>>
>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [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  написал(а):
> 
> 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.
> 

___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] building android aab package help

[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.
>
>
>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Evaluation of Conditional Depends

[Richard Weickelt]

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
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] building android aab package help

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

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.

___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Evaluation of Conditional Depends

[Christian Gudrian]

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

___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs