Looks like my information is out of date since 2013. On Thu, Sep 7, 2017 at 6:52 AM, <[email protected]> wrote:
> 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, >> <[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. > -- -- 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.
