From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 520D5C4363A for ; Tue, 27 Oct 2020 10:58:01 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D07552224E for ; Tue, 27 Oct 2020 10:58:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=citrix.com header.i=@citrix.com header.b="PBSgF0e9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D07552224E Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=citrix.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.12779.33101 (Exim 4.92) (envelope-from ) id 1kXMfa-0002ep-Cb; Tue, 27 Oct 2020 10:57:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 12779.33101; Tue, 27 Oct 2020 10:57:38 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kXMfa-0002ei-9R; Tue, 27 Oct 2020 10:57:38 +0000 Received: by outflank-mailman (input) for mailman id 12779; Tue, 27 Oct 2020 10:57:36 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kXMfY-0002eZ-GM for xen-devel@lists.xenproject.org; Tue, 27 Oct 2020 10:57:36 +0000 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ad703685-fd15-43d8-98a1-faeea2ccb4bf; Tue, 27 Oct 2020 10:57:35 +0000 (UTC) Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kXMfY-0002eZ-GM for xen-devel@lists.xenproject.org; Tue, 27 Oct 2020 10:57:36 +0000 X-Inumbo-ID: ad703685-fd15-43d8-98a1-faeea2ccb4bf Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ad703685-fd15-43d8-98a1-faeea2ccb4bf; Tue, 27 Oct 2020 10:57:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1603796255; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=FlhFwdK4CvQ766qK2/X/WXSTzHrQlYTWB1SqfcIzsFA=; b=PBSgF0e9GTS0yFBEMiOw2/iVZ/DtLvKg6QgLM9uC89fZPTE7YYRBAZuC Fl8PJ9Xz5oRrlQT2g5pzvl2bgAN5Nh4DtqsDphCZ4cI0tcytN2xWCKLm5 1ModNbiKfsFwjQ9LfsPbsRdi/VhmsGJHGDSudJLFSRKAvbZWRijb3Sdmy 4=; Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: fqykTXJDfFdy1dgPWqYRxY0BAob9QP7nut7E7cT8mH7f48OlczC+2StQMxe2igiBbU1WA5eoeY NwGJsN9Le30nhhcMdKjj6BnR4P5nD+DAljg6INpKpImDPX/f8skfhlT1MVUwejY88JT1TE2fWd k8EUuhAOlXEmOpx4OaS+ZR/UaCs3/UL72F5x79ZRfg4O1kUR03nQihmi0nZ6f5YwEVq50OsDxt mlF6CsvFXOofQD6Dq0qn/YPZLkCR/6KMxe3oVsSdYowTNUtErpIjblNNHbqcC+uIp25uUNyqtf qYQ= X-SBRS: None X-MesageID: 29858074 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.77,423,1596513600"; d="scan'208";a="29858074" Subject: Re: [PATCH v1] libacpi: use temporary files for generated files To: Jan Beulich , Olaf Hering CC: Ian Jackson , Wei Liu , References: <20201026204151.23459-1-olaf@aepfle.de> <68312718-c8ad-040b-be45-192d2c91ba8f@suse.com> <20201027112703.24d55a50.olaf@aepfle.de> From: Andrew Cooper Message-ID: <24025dd2-2c61-7e92-a9b1-2433eea2e909@citrix.com> Date: Tue, 27 Oct 2020 10:57:12 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To FTLPEX02CL04.citrite.net (10.13.108.177) On 27/10/2020 10:37, Jan Beulich wrote: > On 27.10.2020 11:27, Olaf Hering wrote: >> Am Tue, 27 Oct 2020 11:16:04 +0100 >> schrieb Jan Beulich : >> >>> This pattern is used when a rule consists of multiple commands >>> having their output appended to one another's. >> My understanding is: a rule is satisfied as soon as the file exists. > No - once make has found that a rule's commands need running, it'll > run the full set and only check again afterwards. It stops at the first command which fails. Olaf is correct, but the problem here is an incremental build issue, not a parallel build issue. Intermediate files must not use the name of the target, or a failure and re-build will use the (bogus) intermediate state rather than rebuilding it. ~Andrew