From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 3BFCE211B76CF for ; Wed, 23 Jan 2019 14:07:14 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EFD412CD814; Wed, 23 Jan 2019 22:07:13 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-117.rdu2.redhat.com [10.10.120.117]) by smtp.corp.redhat.com (Postfix) with ESMTP id 48ADC6B8FC; Wed, 23 Jan 2019 22:07:13 +0000 (UTC) To: "Gao, Liming" Cc: edk2-devel-01 References: <4A89E2EF3DFEDB4C8BFDE51014F606A14E3C0E74@SHSMSX104.ccr.corp.intel.com> From: Laszlo Ersek Message-ID: <43f3143e-80cb-477a-5299-f48af4927997@redhat.com> Date: Wed, 23 Jan 2019 23:07:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E3C0E74@SHSMSX104.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 23 Jan 2019 22:07:14 +0000 (UTC) Subject: Re: parallelism in the module-level, generated GNUmakefile's X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 22:07:15 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/23/19 17:36, Gao, Liming wrote: > Laszlo: By design, BaseTools generates GNUMakefile with the complete > dependency. So, the generated GNUMakefile should support parallelism > run. But, I don't verify this functionality. Have you found any > limitation to forbid parallelism run in module GNUMakefile? No, I haven't, and that is what surprised me :) I *expected* problems, but didn't find any. Given that BaseTools / "build" does not offer any way at all to build a single generated GNUMakefile with "make -j", such parallel builds of said GNUMakefiles have never been tested. Therefore, I expected them to break, under "make -j". When they didn't, I was surprised. :) The question is if we can *rely* on BaseTools to generate the GNUMakefiles with complete dependencies. In other words, if we now start building them with "make -j" (via the outer make), and run into an error due to missing dependencies, can we report a TianoCore BZ about that? Will it be in scope? Is "complete dependencies" an explicit goal? If the answer is "yes", I will happily take that answer. If the answer is "no", then BaseTools should use .NOTPARALLEL in the GNUMakefiles (or else "build" should invoke the inner "make" with an explicit "-j1" flag -- as I've learned today). Thank you! Laszlo