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

[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 ?

[Colin Cross]

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

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

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

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

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