Re: [Qbs] building android aab package help

2020-06-07 Thread 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

2020-06-07 Thread Иван Комиссаров
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

2020-06-07 Thread 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

2020-06-07 Thread Иван Комиссаров
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

2020-04-17 Thread 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.

Le ven. 17 avr. 2020 à 09:16, Christian Kandeler 
a écrit :

> [Redirecting back to the mailing list]
>
> On Thu, 16 Apr 2020 20:17:47 +0200
> Raphael Cotty  wrote:
>
> > Le mer. 15 avr. 2020 à 09:48, Christian Kandeler <
> christian.kande...@qt.io>
> > a écrit :
> >
> > > Building an aab is similar to building apk. They both take the same
> inputs
> > > > (including java files) and generate a java file (R.java) but in a
> > > different
> > > > way.
> > > >
> > > > I first tried to add the android.aab type to the product type
> property in
> > > > order to build both types.
> > > > But I can't find a way to redirect all java files + the R.java apk
> to the
> > > > next apk rule and all the java files + R.java aab to the next aab
> rule
> > > > (without changing the java module).
> > >
> > > I don't understand this part. What is a "next rule"? What do you mean
> by
> > > "redirect"?
> >
> > If I could duplicate the java modules I'd do this:
> > I'd tag all java files in the product to java.java-apk and java.java-aab.
> > The the R.java generated for apk will be tagged java.java-apk
> > The the R.java generated for aab will be tagged java.java-aab
> >
> > One copy of the java modules will have this rule:
> > [java.java-apk] => [java.class-apk]
> > The other copy:
> > [java.java-aab] => [java.class-aab]
> >
> > I'd also have 2 rules for the dex step (identical prepare script)
> > [java.class-apk] => [dex-apk]
> > [java.class-aab] => [dex-aab]
> >
> > Then the 2 final steps (different prepare script):
> > [dex-apk] => [apk]
> > [dex-aab] => [aab]
> >
> > That's obviously horrible. But that shows the 2 paths.
> >
> > But can this be done with qbs without to duplication of code?
>
> The answer depends on my earlier question you did not answer:
>
> > > And what is the apk/aab "context"?
> > > Are you saying you need to build both the APK and the AAB file? If so,
> > > what is the relationship between them?
>
>
> Christian
> ___
> Qbs mailing list
> Qbs@qt-project.org
> https://lists.qt-project.org/listinfo/qbs
>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs


Re: [Qbs] building android aab package help

2020-04-17 Thread Christian Kandeler
[Redirecting back to the mailing list]

On Thu, 16 Apr 2020 20:17:47 +0200
Raphael Cotty  wrote:

> Le mer. 15 avr. 2020 à 09:48, Christian Kandeler 
> a écrit :
> 
> > Building an aab is similar to building apk. They both take the same inputs
> > > (including java files) and generate a java file (R.java) but in a
> > different
> > > way.
> > >
> > > I first tried to add the android.aab type to the product type property in
> > > order to build both types.
> > > But I can't find a way to redirect all java files + the R.java apk to the
> > > next apk rule and all the java files + R.java aab to the next aab rule
> > > (without changing the java module).
> >
> > I don't understand this part. What is a "next rule"? What do you mean by
> > "redirect"?
> 
> If I could duplicate the java modules I'd do this:
> I'd tag all java files in the product to java.java-apk and java.java-aab.
> The the R.java generated for apk will be tagged java.java-apk
> The the R.java generated for aab will be tagged java.java-aab
> 
> One copy of the java modules will have this rule:
> [java.java-apk] => [java.class-apk]
> The other copy:
> [java.java-aab] => [java.class-aab]
> 
> I'd also have 2 rules for the dex step (identical prepare script)
> [java.class-apk] => [dex-apk]
> [java.class-aab] => [dex-aab]
> 
> Then the 2 final steps (different prepare script):
> [dex-apk] => [apk]
> [dex-aab] => [aab]
> 
> That's obviously horrible. But that shows the 2 paths.
> 
> But can this be done with qbs without to duplication of code?

The answer depends on my earlier question you did not answer:

> > And what is the apk/aab "context"?
> > Are you saying you need to build both the APK and the AAB file? If so,
> > what is the relationship between them?


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


Re: [Qbs] building android aab package help

2020-04-15 Thread Christian Kandeler
On Tue, 14 Apr 2020 21:27:18 +0200
Raphael Cotty  wrote:

> I am struggling to find a way to build the aab package (non runnable
> package required by google store) on the android platform.
> For this platform the default qbs product type is changed from application
> to android.apk (runnable package).
> What I am trying to achieve is allowing the user to just set a property in
> his project to enable the build of the aab package:

Note that the property should most probably be in the Android.sdk module 
instead.

> Building an aab is similar to building apk. They both take the same inputs
> (including java files) and generate a java file (R.java) but in a different
> way.
> 
> I first tried to add the android.aab type to the product type property in
> order to build both types.
> But I can't find a way to redirect all java files + the R.java apk to the
> next apk rule and all the java files + R.java aab to the next aab rule
> (without changing the java module).

I don't understand this part. What is a "next rule"? What do you mean by 
"redirect"?


> // Let's gather all compiled java classes and generate the
> classes.dex
> // If running in the apk context then we have all project java
> classes and the
> // R.java generated in the apk context
> // If running in the aab context then we have all project java
> classes and the
> // R.java generated in the aab context

And what is the apk/aab "context"?
Are you saying you need to build both the APK and the AAB file? If so, what is 
the relationship between them?


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


Re: [Qbs] building android aab package help

2020-04-15 Thread Jochen Ulrich
Hi Raphael!

What doesn’t work as expected? Is there any error message or what output is 
missing?


> As a fall back solution I can create a new AndroidAab Product that will 
> depend on the android application and implement all rules using 
> inputsFromDependencies property.

And this works? You already tried this?


Best
Jochen

Von: Qbs  im Auftrag von Raphael Cotty 

Datum: Dienstag, 14. April 2020 um 21:27
An: "qbs@qt-project.org" 
Betreff: [Qbs] building android aab package help

Hi all, 
I am struggling to find a way to build the aab package (non runnable package 
required by google store) on the android platform.
For this platform the default qbs product type is changed from application to 
android.apk (runnable package).
What I am trying to achieve is allowing the user to just set a property in his 
project to enable the build of the aab package:
QtQuiApplication {
    name: "myApp"
    buildAab: true
    ...
}

Building an aab is similar to building apk. They both take the same inputs 
(including java files) and generate a java file (R.java) but in a different way.

I first tried to add the android.aab type to the product type property in order 
to build both types.
But I can't find a way to redirect all java files + the R.java apk to the next 
apk rule and all the java files + R.java aab to the next aab rule (without 
changing the java module).

It looks like I need to multiplex over the product type...
This simple project summaries the issue (assuming product type multiplexing 
exists):
Project {
    Product {
        multiplexByType: ["android.apk", "android.aab"]
        name: "android"

        files: [
            "a.java",
            "b.java"
        ]

        Group {
            files: "AndroidManifest.xml"
            fileTags: "android.manifest_final"
        }

        FileTagger {
            patterns: "*.java"
            fileTags: ["java.java"]
        }

        // Generate the R.java in a different way according to the product type
        Rule {
            inputs: "android.manifest_final"
            Artifact {
                filePath: FileInfo.joinPaths(product.buildDirectory, "R.java")
                fileTags: ["java.java"]
            }
            prepare: {
                var cmd = new JavaScriptCommand();
                cmd.description = "generating R.java";
                cmd.sourceCode = function() {
                    var readFile = TextFile(input.filePath, TextFile.ReadOnly);
                    var writeFile = TextFile(output.filePath, 
TextFile.WriteOnly)
                    writeFile.write(readFile.readAll());
                    if (product.type === "android.apk")
                        writeFile.write("This is the R.java for apk");
                    else
                        writeFile.write("This is the R.java for aab");
                    writeFile.close();
                };
                return [cmd];
            }
        }

        // This rule can't be changed as it comes from the java module
        Rule {
            multiplex: true
            inputs: ["java.java"]
            outputFileTags: ["java.class"]
            outputArtifacts: {
                var artifacts = [];
                for (var i = 0; i < inputs["java.java"].length; ++i) {
                    artifacts.push({
                                       fileTags: "java.class",
                                       filePath: 
FileInfo.joinPaths(product.buildDirectory,
                                                                    
inputs["java.java"][i].baseName + ".class")});
                }
                return artifacts;
            }
            prepare: {
                var cmd = new JavaScriptCommand();
                cmd.description = "compiling java files";
                cmd.sourceCode = function() {
                    for (var i = 0; i < inputs["java.java"].length; ++i) {
                        File.copy(inputs["java.java"][i].filePath,
                                  outputs["java.class"][i].filePath);
                    }
                };
                return [cmd];
            }
        }

        // Let's gather all compiled java classes and generate the classes.dex
        // If running in the apk context then we have all project java classes 
and the
        // R.java generated in the apk context
        // If running in the aab context then we have all project java classes 
and the
        // R.java generated in the aab context
        Rule {
            multiplex: true
            inputs: ["java.class"]
            Artifact {
                filePath: "classes.dex"
                fileTags: ["android.dex"

[Qbs] building android aab package help

2020-04-14 Thread Raphael Cotty
Hi all,
I am struggling to find a way to build the aab package (non runnable
package required by google store) on the android platform.
For this platform the default qbs product type is changed from application
to android.apk (runnable package).
What I am trying to achieve is allowing the user to just set a property in
his project to enable the build of the aab package:
QtQuiApplication {
name: "myApp"
buildAab: true
...
}

Building an aab is similar to building apk. They both take the same inputs
(including java files) and generate a java file (R.java) but in a different
way.

I first tried to add the android.aab type to the product type property in
order to build both types.
But I can't find a way to redirect all java files + the R.java apk to the
next apk rule and all the java files + R.java aab to the next aab rule
(without changing the java module).

It looks like I need to multiplex over the product type...
This simple project summaries the issue (assuming product type multiplexing
exists):
Project {
Product {
multiplexByType: ["android.apk", "android.aab"]
name: "android"

files: [
"a.java",
"b.java"
]

Group {
files: "AndroidManifest.xml"
fileTags: "android.manifest_final"
}

FileTagger {
patterns: "*.java"
fileTags: ["java.java"]
}

// Generate the R.java in a different way according to the product
type
Rule {
inputs: "android.manifest_final"
Artifact {
filePath: FileInfo.joinPaths(product.buildDirectory,
"R.java")
fileTags: ["java.java"]
}
prepare: {
var cmd = new JavaScriptCommand();
cmd.description = "generating R.java";
cmd.sourceCode = function() {
var readFile = TextFile(input.filePath,
TextFile.ReadOnly);
var writeFile = TextFile(output.filePath,
TextFile.WriteOnly)
writeFile.write(readFile.readAll());
if (product.type === "android.apk")
writeFile.write("This is the R.java for apk");
else
writeFile.write("This is the R.java for aab");
writeFile.close();
};
return [cmd];
}
}

// This rule can't be changed as it comes from the java module
Rule {
multiplex: true
inputs: ["java.java"]
outputFileTags: ["java.class"]
outputArtifacts: {
var artifacts = [];
for (var i = 0; i < inputs["java.java"].length; ++i) {
artifacts.push({
   fileTags: "java.class",
   filePath:
FileInfo.joinPaths(product.buildDirectory,

inputs["java.java"][i].baseName + ".class")});
}
return artifacts;
}
prepare: {
var cmd = new JavaScriptCommand();
cmd.description = "compiling java files";
cmd.sourceCode = function() {
for (var i = 0; i < inputs["java.java"].length; ++i) {
File.copy(inputs["java.java"][i].filePath,
  outputs["java.class"][i].filePath);
}
};
return [cmd];
}
}

// Let's gather all compiled java classes and generate the
classes.dex
// If running in the apk context then we have all project java
classes and the
// R.java generated in the apk context
// If running in the aab context then we have all project java
classes and the
// R.java generated in the aab context
Rule {
multiplex: true
inputs: ["java.class"]
Artifact {
filePath: "classes.dex"
fileTags: ["android.dex"]
}
prepare: {
var cmd = new JavaScriptCommand();
cmd.description = "generating classes.dex";
cmd.sourceCode = function() {
var writeFile = TextFile(output.filePath,
TextFile.WriteOnly)
for (var i = 0; i < inputs["java.class"].length; ++i) {
var readFile =
TextFile(inputs["java.class"][i].filePath, TextFile.ReadOnly);
writeFile.write(readFile.readAll());
}
writeFile.close();
};
return [cmd];
}
}

// Generate the apk package
Rule {
multiplex: true
inputs: ["android.dex"]
Artifact {
filePath: product.name + ".apk"
fileTags: "android.apk"
}