ccache changed its license to GPL3, so we are unlikely to upgrade. On Mon, Sep 4, 2017 at 10:58 PM, <[email protected]> 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, > [email protected] 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: >>>> stats print 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 <[email protected]> >>>> 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 [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.
