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 <robert.durk...@gmail.com>
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 android-building@googlegroups.com
> To unsubscribe from this group, send email to
> android-building+unsubscr...@googlegroups.com
> 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 android-building+unsubscr...@googlegroups.com.
> 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 android-building@googlegroups.com
To unsubscribe from this group, send email to
android-building+unsubscr...@googlegroups.com
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 android-building+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
