[android-building] Re: Android O_8.0.0 -Booting Issue while running Emulator

2017-12-15 Thread venkatakrishna . karanamsuryana 
Retry using (system|vendor)*-qemu.img* files if they are produced during 
build at all, and not (system|vendor).img

On Friday, September 29, 2017 at 4:43:29 PM UTC+2, Renjith Rajagopal wrote:
>
> Hi Smart peps here,
>
> I was playing around with Android O AOSP and tried running it for Emulator 
> image.
> But seems like booting is not done properly while I run Emulator for image 
> type - car_emu_x86 as well as for arm version too.
>
> Lunch command produce following result in Android 
>
> 1. aosp_arm-eng
>  2. aosp_arm64-eng
>  3. aosp_mips-eng
>  4. aosp_mips64-eng
>  5. aosp_x86-eng
>  6. aosp_x86_64-eng
>  7. full_fugu-userdebug
>  8. aosp_fugu-userdebug
>  9. car_emu_arm64-userdebug
>  10. car_emu_arm-userdebug
>  11. car_emu_x86_64-userdebug
>  12. car_emu_x86-userdebug
>  13. mini_emulator_arm64-userdebug
>  14. m_e_arm-userdebug
>  15. m_e_mips64-eng
>  16. m_e_mips-userdebug
>  17. mini_emulator_x86_64-userdebug
>  18. mini_emulator_x86-userdebug
>  19. uml-userdebug
>  20. aosp_dragon-userdebug
>  21. aosp_dragon-eng
>  22. aosp_marlin-userdebug
>  23. aosp_marlin_svelte-userdebug
>  24. aosp_sailfish-userdebug
>  25. aosp_angler-userdebug
>  26. aosp_bullhead-userdebug
>  27. aosp_bullhead_svelte-userdebug
>  28. hikey-userdebug
>  29. hikey960-userdebug
>
> I opted for No:12,11,10(3 Emulator images separately) .For all these 
> cases I'm getting the same error.
>
> Attaching the Full Serial log of same(car_emu_arm-userdebug version).
>
> Summary or Issue Log :  init: bool 
> android::init::FirstStageMount::InitRequiredDevices(): partition(s) not 
> found in /sys, waiting for their uevent(s): system
> init: Wait for partitions returned after 10019ms
>
>
> Any pointers will be appreciated !
>
> Thanks in Advance.
>
>
>
>

-- 
-- 
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.

Re: [android-building] Re: How to build and use soong stand-alone?

2017-11-21 Thread venkatakrishna . karanamsuryana 
Well, yes, moving/deleting is an option that worked for me. The problem is 
the AOSP stack we got is from a vendor. They don't care if Android Emulator 
builds or not. But, we would like to use Emulator.
So, I tried compiling emulator x86_64, and it includes 
vendor/whateverVendor/*, and this vendor didn't really write the *.bp files 
intelligently, thus, all their hardware specific stuff is also some 
injected into dependencies.

By deleting the unwanted *.bp files under whateverVendor/ I made some 
progress. But, like I said, we must be able to build both the vendor lunch 
target, and emulator.

So, I was wondering if I can somehow ask the build tools(soong, ninja, 
bpblob or the family) to not read some of the *.bp files I specify, and
if I could specify at all, where should I do it.

thanks

On Monday, November 20, 2017 at 9:57:21 PM UTC+1, Wesolowski, Krzysztof 
wrote:
>
> Top level Android.bp globs for /vendor/*/* subdirs so matching Android.bp 
> would be /vendor/*/*/Android.bp, so as far as I understand assumption is 
> that vendor/whateverVendor/whateverModule/Android.bp should be under your 
> control, and you control what will happen deeper.
>
>  
>
> I guess that whateverModule is either empty directory or git repo – so you 
> can move/remove it by editing manifets.
>
>  
>
> BR, K.
>
>  
>
> *From:* android-...@googlegroups.com  [mailto:
> android-...@googlegroups.com ] *On Behalf Of *
> venkatakrishna...@gmail.com 
> *Sent:* Monday, November 20, 2017 13:31
> *To:* Android Building 
> *Subject:* [android-building] Re: How to build and use soong stand-alone?
>
>  
>
> Is there any way to ignore certain Android.bp files from being globbed? 
> For instance to not include/glob any vendor/whateverVendor/* and the *.bp 
> files further down in that directory.
>
> thanks,
> Venkat.
>
> On Thursday, October 12, 2017 at 10:40:11 PM UTC+2, Hartmut Goebel wrote:
>
> Hallo, 
>
> I'm going to build the Android platform-tools as stand-alone packages 
> for a Linux-distribution (GuisSD). For this it seems to make sense to 
> switch to the new soong-based build system. 
>
> 1. How to I build soong without installing a full-blown Android build 
> environment? 
> 2. How to install soong to be used outside the Android build environment? 
> 3. How to use soong without or outside the Android build environment? 
>
>
> Re. 1.: I managed to start bootstrapping soong as follows: 
>
> mkdir /tmp/sing-song/ 
> cd /tmp/sing-song/ 
>
> cp -r /tmp/soong-8.0.0_r17-checkout source 
> cd source/ 
>
> mkdir build 
> ln -s .. build/soong 
> cp -r /tmp/blueprint-8.0.0_r17-checkout/ build/blueprint 
>
> cd .. 
> $PWD/source/bootstrap.bash 
>
> This will give me 
>   .blueprint.bootstrap 
>   .bootstrap/ 
>   .minibootstrap/ 
>   soong -> /tmp/foo/source/build/soong/soong.bash 
>   .soong.bootstrap 
>
> Now when I run ./soong I get these errors: 
>
> error: Android.bp:13:9: "androidmk/Blueprints": not found 
> error: Android.bp:13:9: "cmd/*/Blueprints": not found 
> error: Android.bp:13:9: "third_party/zip/Blueprints": not found 
> error: Android.bp:13:9: "ui/*/Blueprints": not found 
> ninja: error: rebuilding '/tmp/sing-song/.minibootstrap/build.ninja': 
> subcommand failed 
>
>
>
> Re 2.: Both soong and soong_ui are bash-scripts, checking if a new 
> version needs to be bootstrapped – which will never be the case if they 
> are installed vi some Linux package management. So how can these be 
> installed into e.g. /usr/bin? How to make these scripts to *not* try to 
> bootstrap soong? 
>
> Re. 3: How is soong meant to be used? Unfortunately there is not even a 
> short usage-instruction in the archive :-( 
>
> Thanks in advance for any tips. 
>
>
> -- 
> Regards 
> Hartmut Goebel 
>
> | Hartmut Goebel  | h.go...@crazy-compilers.com   | 
> | www.crazy-compilers.com | compilers which you thought are impossible | 
>
> -- 
> -- 
> You received this message because you are subscribed to the "Android 
> Building" mailing list.
> To post to this group, send email to android...@googlegroups.com 
> 
> To unsubscribe from this group, send email to
> android-buildi...@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-buildi...@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

[android-building] Re: How to build and use soong stand-alone?

2017-11-20 Thread venkatakrishna . karanamsuryana 
Is there any way to ignore certain Android.bp files from being globbed? 
For instance to not include/glob any vendor/whateverVendor/* and the *.bp 
files further down in that directory.

thanks,
Venkat.

On Thursday, October 12, 2017 at 10:40:11 PM UTC+2, Hartmut Goebel wrote:
>
> Hallo, 
>
> I'm going to build the Android platform-tools as stand-alone packages 
> for a Linux-distribution (GuisSD). For this it seems to make sense to 
> switch to the new soong-based build system. 
>
> 1. How to I build soong without installing a full-blown Android build 
> environment? 
> 2. How to install soong to be used outside the Android build environment? 
> 3. How to use soong without or outside the Android build environment? 
>
>
> Re. 1.: I managed to start bootstrapping soong as follows: 
>
> mkdir /tmp/sing-song/ 
> cd /tmp/sing-song/ 
>
> cp -r /tmp/soong-8.0.0_r17-checkout source 
> cd source/ 
>
> mkdir build 
> ln -s .. build/soong 
> cp -r /tmp/blueprint-8.0.0_r17-checkout/ build/blueprint 
>
> cd .. 
> $PWD/source/bootstrap.bash 
>
> This will give me 
>   .blueprint.bootstrap 
>   .bootstrap/ 
>   .minibootstrap/ 
>   soong -> /tmp/foo/source/build/soong/soong.bash 
>   .soong.bootstrap 
>
> Now when I run ./soong I get these errors: 
>
> error: Android.bp:13:9: "androidmk/Blueprints": not found 
> error: Android.bp:13:9: "cmd/*/Blueprints": not found 
> error: Android.bp:13:9: "third_party/zip/Blueprints": not found 
> error: Android.bp:13:9: "ui/*/Blueprints": not found 
> ninja: error: rebuilding '/tmp/sing-song/.minibootstrap/build.ninja': 
> subcommand failed 
>
>
>
> Re 2.: Both soong and soong_ui are bash-scripts, checking if a new 
> version needs to be bootstrapped – which will never be the case if they 
> are installed vi some Linux package management. So how can these be 
> installed into e.g. /usr/bin? How to make these scripts to *not* try to 
> bootstrap soong? 
>
> Re. 3: How is soong meant to be used? Unfortunately there is not even a 
> short usage-instruction in the archive :-( 
>
> Thanks in advance for any tips. 
>
>
> -- 
> Regards 
> Hartmut Goebel 
>
> | Hartmut Goebel  | h.go...@crazy-compilers.com  
>   | 
> | www.crazy-compilers.com | compilers which you thought are impossible | 
>
>

-- 
-- 
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.

Re: [android-building] Android 7.0 build system doesn't generate .P ?

2017-09-07 Thread venkatakrishna . karanamsuryana 
Well, you are already using version ccache 3.1.9 in Oreo release - 
https://android.googlesource.com/platform/prebuilts/misc/+/85bf1819a733f1c5c87e1a1574e52badf9abfa56/linux-x86/ccache/
 
which as I currently see is licensed under GPL 3 or higher.
I wonder if I'm missing something.

On Tuesday, September 5, 2017 at 7:27:50 PM UTC+2, Colin Cross wrote:
>
> ccache changed its license to GPL3, so we are unlikely to upgrade. 
>
> On Mon, Sep 4, 2017 at 10:58 PM, 
>  wrote: 
> > Hello, 
> > And if I got all that I said in the previous email correct, then, 
> > from ccache point of view, the fix is to use newer ccache version - 
> > https://ccache.samba.org/releasenotes.html#_ccache_3_3 
> > I'm curious to know if AOSP O r4  branch has any plans to user newer 
> ccache. 
> > 
> > regards, 
> > Venkat. 
> > 
> > 
> > On Monday, September 4, 2017 at 4:57:47 PM UTC+2, 
> > venkatakrishna...@gmail.com wrote: 
> >> 
> >> Hello, 
> >> I suspect a potential side-effect when Ninja, and ccache(shared with 
> >> multiple users on a workstation) are working together. 
> >> Consider the following scenario. This assumes a shared cache(CCACHE_DIR 
> >> set to /ccache/common_cachestore) for both the users. 
> >> 
> >> User A runs a build under /ws/aosp_A for a particular revision of AOSP, 
> >> and he produces the cache at /ccache/common_cachestore 
> >> User B runs a build under /ws/aosp_B, and for some of the files, cache 
> hit 
> >> occurs, thus, all the compiler data is copied into user B's 
> workspace.(this 
> >> includes the .d file) and thus, the Ninja dependency database now 
> points to 
> >> the system headers from user A's workspace, because, ccache had 
> produced .d 
> >> file with system header paths which are absolute, and thus, they point 
> to 
> >> user A's workspace. 
> >> 
> >> Now, User B fetches updated content by doing a repo sync, and lets 
> assume 
> >> the system headers are newer Or he deliberately changed some system 
> headers 
> >> for some reason. 
> >> However, Ninja's dependency database points to the system headers from 
> >> User A's workspace, thus, it may so happen that it doesn't rebuild. 
> >> 
> >> (It is likely that I'm missing the very technical details of Ninja's 
> >> dependency database. Also, this is a once in blue moon scenario) 
> >> With an assumption that this is possible, I'm trying to think of a way 
> to 
> >> have relative paths to system headers. 
> >> 
> >> Do I have a point? If I do, apparently, shared ccache should not be 
> used 
> >> at all with AOSP? 
> >> thanks for your feedback in advance, 
> >> 
> >> Best regards, 
> >> Venkat. 
> >> 
> >> 
> >> On Friday, September 2, 2016 at 4:06:00 PM UTC+2, Chih-Wei Huang wrote: 
> >>> 
> >>> It's very helpful. 
> >>> Thank you very much! 
> >>> 
> >>> Dan Willemsen於 2016年9月1日星期四 UTC+8下午10時30分18秒寫道： 
>  
>  We've switched to using ninja to do our builds, which defaults to 
>  reading the depfile into it's database, then deleting it. You can 
> either 
>  keep the depfile: 
>  
>    NINJA_ARGS="-d keepdepfile" m ... 
>  
>  Or just ask ninja what the deps are for a specific file: 
>  (NINJA_EXTRA_ARGS has to be empty as a workaround in this case) 
>  
>    NINJA_ARGS= "-t deps out/...o" m NINJA_EXTRA_ARGS= 
>  
>  You can also see some of the other ninja tools and debug modes that 
> are 
>  useful with -d/-t list: 
>  
>  ninja subtools: 
>  browse  browse dependency graph in a web browser 
>   clean  clean built files 
>    commands  list all commands required to rebuild given targets 
>    deps  show dependencies stored in the deps log 
>   graph  output graphviz dot file for targets 
>   query  show inputs/outputs for a path 
> targets  list targets by their rule or depth in the DAG 
>  compdb  dump JSON compilation database to stdout 
>   recompact  recompacts ninja-internal data structures 
>  
>  debugging modes: 
>    statsprint operation counts/timing info 
>    explain  explain what caused a command to execute 
>    keepdepfile  don't delete depfiles after they're read by ninja 
>    keeprsp  don't delete @response files on success 
>  multiple modes can be enabled via -d FOO -d BAR 
>  
>  
>  On Thu, Sep 1, 2016 at 7:05 AM Chih-Wei Huang  
>
>  wrote: 
> > 
> > Hi, 
> > Anyone knows why Android 7.0 build system doesn't generate 
> > the .P file, the dependency file of the .o to be included? 
> > Without the .P file it's hard to debug the dependency issue. 
> > Or any alternative way to check the dependency of the .o in Android 
> > 7.0? 
> > 
> > -- 
> > 
> > -- 
> > -- 
> > You received this message because you are subscribed to the "Android 
> > Building" mailing list. 
> > To post to this group, send email to

Re: [android-building] Android 7.0 build system doesn't generate .P ?

2017-09-05 Thread venkatakrishna . karanamsuryana 
Hello,
And if I got all that I said in the previous email correct, then,
from ccache point of view, the fix is to use newer ccache version - 
https://ccache.samba.org/releasenotes.html#_ccache_3_3
I'm curious to know if AOSP O r4  branch has any plans to user newer ccache.

regards,
Venkat.

On Monday, September 4, 2017 at 4:57:47 PM UTC+2, 
venkatakrishna...@gmail.com wrote:
>
> Hello,
> I suspect a potential side-effect when Ninja, and ccache(shared with 
> multiple users on a workstation) are working together.
> Consider the following scenario. This assumes a shared cache(CCACHE_DIR 
> set to /ccache/common_cachestore) for both the users.
>
> User A runs a build under /ws/aosp_A for a particular revision of AOSP, 
> and he produces the cache at /ccache/common_cachestore
> User B runs a build under /ws/aosp_B, and for some of the files, cache hit 
> occurs, thus, all the compiler data is copied into user B's workspace.(this 
> includes the .d file) and thus, the Ninja dependency database now points to 
> the system headers from user A's workspace, because, ccache had produced .d 
> file with system header paths which are absolute, and thus, they point to 
> user A's workspace.
>
> Now, User B fetches updated content by doing a repo sync, and lets assume 
> the system headers are newer Or he deliberately changed some system headers 
> for some reason. 
> However, Ninja's dependency database points to the system headers from 
> User A's workspace, thus, it *may *so happen that it doesn't rebuild.
>
> (It is likely that I'm missing the very technical details of Ninja's 
> dependency database. Also, this is a once in blue moon scenario)
> With an assumption that this is possible, I'm trying to think of a way to 
> have relative paths to system headers. 
>
> Do I have a point? If I do, apparently, shared ccache should not be used 
> at all with AOSP?
> thanks for your feedback in advance,
>
> Best regards,
> Venkat.
>
>
> On Friday, September 2, 2016 at 4:06:00 PM UTC+2, Chih-Wei Huang wrote:
>>
>> It's very helpful.
>> Thank you very much!
>>
>> Dan Willemsen於 2016年9月1日星期四 UTC+8下午10時30分18秒寫道：
>>>
>>> We've switched to using ninja to do our builds, which defaults to 
>>> reading the depfile into it's database, then deleting it. You can either 
>>> keep the depfile:
>>>
>>>   NINJA_ARGS="-d keepdepfile" m ...
>>>
>>> Or just ask ninja what the deps are for a specific file: 
>>> (NINJA_EXTRA_ARGS has to be empty as a workaround in this case)
>>>
>>>   NINJA_ARGS= "-t deps out/...o" m NINJA_EXTRA_ARGS=
>>>
>>> You can also see some of the other ninja tools and debug modes that are 
>>> useful with -d/-t list:
>>>
>>> ninja subtools:
>>> browse  browse dependency graph in a web browser
>>>  clean  clean built files
>>>   commands  list all commands required to rebuild given targets
>>>   deps  show dependencies stored in the deps log
>>>  graph  output graphviz dot file for targets
>>>  query  show inputs/outputs for a path
>>>targets  list targets by their rule or depth in the DAG
>>> compdb  dump JSON compilation database to stdout
>>>  recompact  recompacts ninja-internal data structures
>>>
>>> debugging modes:
>>>   statsprint operation counts/timing info
>>>   explain  explain what caused a command to execute
>>>   keepdepfile  don't delete depfiles after they're read by ninja
>>>   keeprsp  don't delete @response files on success
>>> multiple modes can be enabled via -d FOO -d BAR
>>>
>>>
>>> On Thu, Sep 1, 2016 at 7:05 AM Chih-Wei Huang  
>>> wrote:
>>>
 Hi,
 Anyone knows why Android 7.0 build system doesn't generate
 the .P file, the dependency file of the .o to be included?
 Without the .P file it's hard to debug the dependency issue.
 Or any alternative way to check the dependency of the .o in Android 7.0?

 -- 

>>>

-- 
-- 
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.

[android-building] Re: unable to build intermediate files for a new HAL service(inside hardware/interfaces)

2017-09-04 Thread venkatakrishna . karanamsuryana 
Hello,
I presume you solved this! Otherwise, here is my guess.

Be sure that your Android.[mk|bp] files are being included at the first 
place. (edit them with some syntactically incorrect data, and see if soong 
complains) If these are included, then, the rest should actually work fine.
At least, in my case, that was the root cause.

The other potential reason could be that you haven't listed your service 
executable in PRODUCT_PACKAGES OR the library in LOCAL_SHARED_LIBRARIES
I hope this helps.

regards,
Venkat.

On Saturday, August 26, 2017 at 7:07:17 PM UTC+2, cesar leon wrote:
>
> I just created a new basic HAL interface and his proper service, created 
> the .mk and .bp files to build intermediate files.
>
> When i compile the code the intermediate JAVA_CLASSES are not being 
> generated, wonder if i need to tell soong somehow that this new HAL should 
> be compiled, can you point me where to look at?
>
> i have followed all the steps from here(
> https://source.android.com/devices/architecture/hidl-cpp/).
>
> i even created a copy of Usb HAL service and rename it to MyUsb, changed 
> all the namespaces to this new one, and the intermediate are not being 
> generated, neither the service.
>
> kind regards
>
>
>

-- 
-- 
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.

Re: [android-building] Android 7.0 build system doesn't generate .P ?

2017-09-04 Thread venkatakrishna . karanamsuryana 
Hello,
I suspect a potential side-effect when Ninja, and ccache(shared with 
multiple users on a workstation) are working together.
Consider the following scenario. This assumes a shared cache(CCACHE_DIR set 
to /ccache/common_cachestore) for both the users.

User A runs a build under /ws/aosp_A for a particular revision of AOSP, and 
he produces the cache at /ccache/common_cachestore
User B runs a build under /ws/aosp_B, and for some of the files, cache hit 
occurs, thus, all the compiler data is copied into user B's workspace.(this 
includes the .d file) and thus, the Ninja dependency database now points to 
the system headers from user A's workspace, because, ccache had produced .d 
file with system header paths which are absolute, and thus, they point to 
user A's workspace.

Now, User B fetches updated content by doing a repo sync, and lets assume 
the system headers are newer Or he deliberately changed some system headers 
for some reason. 
However, Ninja's dependency database points to the system headers from User 
A's workspace, thus, it *may *so happen that it doesn't rebuild.

(It is likely that I'm missing the very technical details of Ninja's 
dependency database. Also, this is a once in blue moon scenario)
With an assumption that this is possible, I'm trying to think of a way to 
have relative paths to system headers. 

Do I have a point? If I do, apparently, shared ccache should not be used at 
all with AOSP?
thanks for your feedback in advance,

Best regards,
Venkat.


On Friday, September 2, 2016 at 4:06:00 PM UTC+2, Chih-Wei Huang wrote:
>
> It's very helpful.
> Thank you very much!
>
> Dan Willemsen於 2016年9月1日星期四 UTC+8下午10時30分18秒寫道：
>>
>> We've switched to using ninja to do our builds, which defaults to reading 
>> the depfile into it's database, then deleting it. You can either keep the 
>> depfile:
>>
>>   NINJA_ARGS="-d keepdepfile" m ...
>>
>> Or just ask ninja what the deps are for a specific file: 
>> (NINJA_EXTRA_ARGS has to be empty as a workaround in this case)
>>
>>   NINJA_ARGS= "-t deps out/...o" m NINJA_EXTRA_ARGS=
>>
>> You can also see some of the other ninja tools and debug modes that are 
>> useful with -d/-t list:
>>
>> ninja subtools:
>> browse  browse dependency graph in a web browser
>>  clean  clean built files
>>   commands  list all commands required to rebuild given targets
>>   deps  show dependencies stored in the deps log
>>  graph  output graphviz dot file for targets
>>  query  show inputs/outputs for a path
>>targets  list targets by their rule or depth in the DAG
>> compdb  dump JSON compilation database to stdout
>>  recompact  recompacts ninja-internal data structures
>>
>> debugging modes:
>>   statsprint operation counts/timing info
>>   explain  explain what caused a command to execute
>>   keepdepfile  don't delete depfiles after they're read by ninja
>>   keeprsp  don't delete @response files on success
>> multiple modes can be enabled via -d FOO -d BAR
>>
>>
>> On Thu, Sep 1, 2016 at 7:05 AM Chih-Wei Huang  
>> wrote:
>>
>>> Hi,
>>> Anyone knows why Android 7.0 build system doesn't generate
>>> the .P file, the dependency file of the .o to be included?
>>> Without the .P file it's hard to debug the dependency issue.
>>> Or any alternative way to check the dependency of the .o in Android 7.0?
>>>
>>> -- 
>>>
>>

-- 
-- 
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.