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] <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, > > [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] > <javascript:> > > To unsubscribe from this group, send email to > > [email protected] <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 [email protected] <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 [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.
