You can get ninja to print the commands it would run with -t commands. You
can do that in the Android build with:
NINJA_ARGS="-t commands droid" m
droid is the default goal, you can replace it with any other goal you want,
including a module name ("framework"), an installed file ("$(getbuildvar
PRODUCT_OUT)/system/framework/framework.jar"), or an intermediate
("out/soong/.intermediates/frameworks/base/framework/android_common/combined/framework.jar").
On Fri, Jan 18, 2019 at 9:02 AM Robert Durkacz <[email protected]>
wrote:
> I thank JBQ for addressing my question. It is phrased as an objection to
> my proposal but I find that it is really in support because it allows me to
> point out that what I am asking for is perfectly normal and possible.
>
> JBQ wrote:
> "There are three main parts to a build system: figuring out what the
> possible commands are, figuring out which of those commands need to run and
> in which order, and actually running them.
>
> "While a shell script would conceivably be able to express the first one,
> it would struggle with some of the the second part (especially around
> incremental builds), and a readable implementation of the third part would
> likely be sequential, resulting in impractically long build times."
>
> I think there are two main parts because the first part is specified by
> the programmer, the one who sets up the build. In 'make' that is called
> the recipes.
> For the programmer who is using that build system, it can be beneficial to
> run the next two parts separately because this gives visibility and
> accessibility when things go wrong or to do something a little different to
> what the original programmer might have thought of (including transferring
> to a different build system).
> make can do the second part separately with the -n option. It produces a
> script, which can be executed, thereby doing the third part separately and
> allowing any amount of intervention between parts two and three.
>
> It is quite true that the script is just a sequence of commands and does
> not reflect make's option (-j) to execute commands in parallel processes. I
> would class it is an interesting question whether you could retain
> parallelism somehow while going through a script as an intermediate step. I
> would not think of it as such an obstacle to give up the script option
> entirely.
>
> If a script is too much to expect then at least a transcript of the
> commands that the build system executes would be almost as good if these
> could be captured and turned into a script.
>
> Android not so long ago would have used make. Whatever benefits were
> gained by going to a new and seemingly complex system, did they really
> require throwing away these beneficial features of make that give a
> programmer a way to take control of the build process?
>
>
>>
>>> --
>> --
>>
>> --
> --
> You received this message because you are subscribed to the "Android
> Building" mailing list.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/android-building?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Android Building" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
--
You received this message because you are subscribed to the "Android Building"
mailing list.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-building?hl=en
---
You received this message because you are subscribed to the Google Groups
"Android Building" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
