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 <cwh...@android-x86.org> >> 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.
