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, > <venkatakrishna.karanamsury...@gmail.com <javascript:>> 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: > >>>> 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-...@googlegroups.com > <javascript:> > > To unsubscribe from this group, send email to > > android-buildi...@googlegroups.com <javascript:> > > 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-buildi...@googlegroups.com <javascript:>. > > 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 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.
