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.
