From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.65; helo=mga03.intel.com; envelope-from=ruiyu.ni@intel.com; receiver=edk2-devel@lists.01.org Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 88DD72095E52D for ; Fri, 29 Sep 2017 22:11:03 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Sep 2017 22:14:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,456,1500966000"; d="scan'208";a="1177221157" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga001.jf.intel.com with ESMTP; 29 Sep 2017 22:14:19 -0700 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 29 Sep 2017 22:14:19 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 29 Sep 2017 22:14:19 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.152]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.98]) with mapi id 14.03.0319.002; Sat, 30 Sep 2017 13:14:16 +0800 From: "Ni, Ruiyu" To: "Gao, Liming" , Laszlo Ersek , "Zhu, Yonghong" , "edk2-devel@lists.01.org" CC: "Kinney, Michael D" , "Shaw, Kevin W" Thread-Topic: [edk2] [Patch V2] Build spec: add description for build with binary cache Thread-Index: AQHTMRNQ2nTA0BUI1UeQN/jx1nZSHKLJvDKAgAACD4CAAqxZgIAAiN1w Date: Sat, 30 Sep 2017 05:14:16 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5BA83A85@SHSMSX104.ccr.corp.intel.com> References: <1505803680-15860-1-git-send-email-yonghong.zhu@intel.com> <0dbfc584-f13c-c712-0ef5-bf1741b89bcd@redhat.com> <04e10841-f112-e2eb-2188-dd930178e150@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E16714F@SHSMSX104.ccr.corp.intel.com> In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E16714F@SHSMSX104.ccr.corp.intel.com> Accept-Language: en-US, zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [Patch V2] Build spec: add description for build with binary cache X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2017 05:11:03 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If use both flags is same as --hash. Can we just get rid of --hash and just use the existing two flags? In this way, we can hide the internal implementation of how to check modifi= cation. Thanks/Ray > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ga= o, > Liming > Sent: Saturday, September 30, 2017 1:03 PM > To: Laszlo Ersek ; Zhu, Yonghong > ; edk2-devel@lists.01.org > Cc: Kinney, Michael D ; Shaw, Kevin W > > Subject: Re: [edk2] [Patch V2] Build spec: add description for build with= binary > cache >=20 > Laszlo: > --binary-destination is to cache the generated binary in this directory= , --binary- > source is to fetch the cached binary from this directory. If they are use= d > together, the behavior will be same that --hash option only and Build out= put > directory. We don't think it is the necessary usage model. So, we don't a= dd this > support. If you have the real case that depends on their combination, we = can > plan to add it. >=20 > Thanks > Liming > >-----Original Message----- > >From: Laszlo Ersek [mailto:lersek@redhat.com] > >Sent: Thursday, September 28, 2017 8:14 PM > >To: Zhu, Yonghong ; edk2-devel@lists.01.org > >Cc: Kinney, Michael D ; Shaw, Kevin W > >; Gao, Liming > >Subject: Re: [edk2] [Patch V2] Build spec: add description for build > >with binary cache > > > >On 09/28/17 14:06, Laszlo Ersek wrote: > > > >> So, how can I invalidate all the cached values? Is it enough to > >> delete the *.hash files? > > > >... I'm asking because I tried the --binary-destination option as well, > >and in the bin cache directory, *.depex and *.inf files were stored as > >well, not just *.hash values. > > > >So I figure, whatever gets stored in the binary cache directory, should > >be deleted when I'd like to invalidate the cache. > > > >Now, removing this separate cache directory altogether would solve my > >question; but that would require me to use "--binary-destination" and > >"--binary-source" together. The idea is that "--hash" would fetch the > >hash values from that separate directory, and it would also write the > >new hash values back to that directory. In addition this directory > >would be very easy to remove, so "--hash" would know whenever the hash > >was empty. > > > >However, it looks like "--binary-destination" and "--binary-source" > >cannot be used together. Why is that? > > > >Thanks, > >Laszlo > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel