From patchwork Mon May 28 21:10:28 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Yann E. MORIN" X-Patchwork-Id: 10434013 X-Patchwork-Delegate: herbert@gondor.apana.org.au Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 40B6860249 for ; Mon, 28 May 2018 21:10:37 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2EB91284DA for ; Mon, 28 May 2018 21:10:37 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1FE332852B; Mon, 28 May 2018 21:10:37 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 348322852A for ; Mon, 28 May 2018 21:10:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934138AbeE1VKe (ORCPT ); Mon, 28 May 2018 17:10:34 -0400 Received: from mail-wr0-f182.google.com ([209.85.128.182]:35613 "EHLO mail-wr0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933737AbeE1VKe (ORCPT ); Mon, 28 May 2018 17:10:34 -0400 Received: by mail-wr0-f182.google.com with SMTP id i14-v6so22093273wre.2 for ; Mon, 28 May 2018 14:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id; bh=QaJEz/SnlgguivqiZtaSOXNNvnJxT2A8kRwWQPB4wzg=; b=Vx3A2mEs6kPrc+IebyLkYHOnUuehc0fdiDGY0fBBlOPw8dch6Ncc775/G4Ipm/NxRi LzkRrZ/V9DD7JOR8du/HQ8n7kEAMy4k8YifQVDoIYHVPG4hQ8YJiuBV/G3wbvgmNwPfl tWUXmbzDKLcUzGLV1ZsJyvGE/JTN7vSu+wPwnyhV5kwAU1APLi9laMUnmDUBriLWCKUH EMK0XZQnPxdVcLKSBcF0zmOV6yh7UZ6HHKA0OnT6ftmynbzUorss54U3r1HrkPz7g4vE YCb905dAZK2AfE17i1ztYyKHcKmZ21nYk6Z0jkOvqI7/q+Se6rlQQjFuzy004g6x3D6u xsOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id; bh=QaJEz/SnlgguivqiZtaSOXNNvnJxT2A8kRwWQPB4wzg=; b=sKpfGMpuJENq/e6KR+BoDjjkeQErAl9DH/071/ZMRq65C4pyim0FrZwQTqUgdbcR3t fN8JYwSdK2Cd8rC96UOutRIHNcwCe2AMAvTGg9ogRPJ8KU/MKf5fiUVBGz0W+Eju25B4 EOS7UCbHZPzUOxnsHp7GPehjAFt0WIN49FcR6iyFQih64HOL0CSpzTwLDOBfpceWzrn0 fxI3iSXdRCcRIX4aAG2h4DL3suO9yjgBOqbyZJ6TEsq/Q+MyOcYIXz3v03n20s6iHFg3 /bjNdcsECSCpuM2Zg/hQkRAU1abw0Pocs2MpJINNURRUuqbc5jRqVfp4yGc08smUZX8W ST7g== X-Gm-Message-State: ALKqPwfN5c8LBvjh5sIWWL3re83H2B/jUAOvvNIYFj7lld4gMSeSdvao Q83zq5+ZTbVRfcBNchDQ1GwAtg== X-Google-Smtp-Source: ADUXVKLmwYnEL7nGDCrJlQbqyCIElSBP34lZJN9qWemh21Gqh36IAOEq386HcQ8Rs1TtKCtdg5diyw== X-Received: by 2002:a5d:4141:: with SMTP id c1-v6mr1819333wrq.129.1527541832654; Mon, 28 May 2018 14:10:32 -0700 (PDT) Received: from scaer.bzh.lan (2a01cb088610730081fd7eea83c08e89.ipv6.abo.wanadoo.fr. [2a01:cb08:8610:7300:81fd:7eea:83c0:8e89]) by smtp.gmail.com with ESMTPSA id b16-v6sm30062495wrm.89.2018.05.28.14.10.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 May 2018 14:10:31 -0700 (PDT) From: "Yann E. MORIN" To: dash@vger.kernel.org Cc: "Yann E. MORIN" , Baruch Siach Subject: [PATCH] [BUILD] fix parallel build Date: Mon, 28 May 2018 23:10:28 +0200 Message-Id: <20180528211028.24130-1-yann.morin.1998@free.fr> X-Mailer: git-send-email 2.14.1 Sender: dash-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dash@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP When neither token.h nor token_var.h exist, and we are building in parallel, it is possible that make will spawn two mktokens at roughly the same time, because of two different rules, one that needs token.h ad another that need token_vars.h. For example, make can have a dependency chain toward just token.h, from syntax.c, and another dependency chain toweard token_vars.h from the generic BUILT_SOURCES. So, make will "quickly" decide that it needs token.h, then spawn mktoken. A bit later, while that mktoken still runs but hasn't yet created token_vars.h, make will need it, and thus spawn a second mktoken. While the second one runs, the first terminates. However, the token.h it had generated has been in the meantime overwritten by the second mktoken that is still generating it, and token.h is still empty. But make proceeds to the rule that required token.h in the first place, and the still-empty token.h gets icluded from a C file, and the build fails because of missing defines. For example: http://autobuild.buildroot.org/results/fc4/fc4e4ab47455ac47dd4a3a60083cec2848e74dbb/build-end.log Fix that by serialising both headers. Reported-by: Baruch Siach Signed-off-by: "Yann E. MORIN" Cc: Baruch Siach --- src/Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/Makefile.am b/src/Makefile.am index 46399c7..5bf5a52 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -44,7 +44,8 @@ EXTRA_DIST = \ mktokens mkbuiltins builtins.def.in mkinit.c \ mknodes.c nodetypes nodes.c.pat mksyntax.c mksignames.c -token.h token_vars.h: mktokens +token_vars.h: token.h +token.h: mktokens $(SHELL) $^ builtins.def: builtins.def.in $(top_builddir)/config.h