From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Wed, 17 Jul 2019 03:21:57 -0700 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B0BDE3087931; Wed, 17 Jul 2019 10:21:56 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-5.ams2.redhat.com [10.36.117.5]) by smtp.corp.redhat.com (Postfix) with ESMTP id 16CE75D71D; Wed, 17 Jul 2019 10:21:54 +0000 (UTC) Subject: Re: [PATCH 1/1] edksetup.sh: rework python executable scanning To: "Gao, Liming" , Leif Lindholm Cc: "devel@edk2.groups.io" , Rebecca Cran , "Feng, Bob C" , "Kinney, Michael D" , "afish@apple.com" References: <20190716190754.25412-1-leif.lindholm@linaro.org> <20579d07-778d-ef9f-9226-25e9629fa2d5@redhat.com> <20190716220449.r7kfozr7yaasi64k@bivouac.eciton.net> <4A89E2EF3DFEDB4C8BFDE51014F606A14E4A974D@SHSMSX104.ccr.corp.intel.com> From: "Laszlo Ersek" Message-ID: <6d14f24e-34ed-ea7f-3921-9c09604a9628@redhat.com> Date: Wed, 17 Jul 2019 12:21:53 +0200 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: <4A89E2EF3DFEDB4C8BFDE51014F606A14E4A974D@SHSMSX104.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Wed, 17 Jul 2019 10:21:56 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 07/17/19 05:23, Gao, Liming wrote: > Leif: > I agree to discuss the behavior first, then review the code logic in detail. I add my comments below. > >> -----Original Message----- >> From: Leif Lindholm [mailto:leif.lindholm@linaro.org] >> Sent: Wednesday, July 17, 2019 6:05 AM >> To: Laszlo Ersek >> Cc: devel@edk2.groups.io; Rebecca Cran ; Feng, Bob C ; Gao, Liming >> ; Kinney, Michael D ; afish@apple.com >> Subject: Re: [PATCH 1/1] edksetup.sh: rework python executable scanning >> - What does PYTHON3_ENABLE mean? Is it for probing only, or are we >> setting it for later use by BaseTools? > > PYTHON3_EANBLE is to decide python3 enable or not. It has high priority. > Once it is set, PYTHON_COMMAND will be ignored. > If it is set to TRUE, edksetup.sh will find Python3 in the system, set PYTHON_COMMAND env. > If it is set to other value, edksetup.sh will find Python3 in the system, set PYTHON_COMMAND env. > If PYTHON3_EANBLE is not set, PYTHON_COMMAND will be used if PYTHON_COMMAND is set. > If PYTHON3_EANBLE is not set, and PYTHON_COMMAND is not set, the default behavior will set PYTHON3_EANBLE to TRUE. I find this confusing. Basically, PYTHON3_EANBLE says, "ignore PYTHON_COMMAND, just go for the highest python3 version". But that is the exact same behavior as if the user didn't set *either* PYTHON3_EANBLE *or* PYTHON_COMMAND. So why do we have two configurations for the exact same behavior? Namely (to repeat): (1) PYTHON3_EANBLE is set to a non-null string: PYTHON_COMMAND is ignored, and we pick the highest minor version of python3. (2) PYTHON3_EANBLE is unset, and PYTHON_COMMAND is unset: we pick the highest minor version of python3. Those configurations -- evoking identical behavior -- could be collapsed into one configuration, namely, if we simply eliminated PYTHON3_EANBLE, and relied on PYTHON_COMMAND only. Here's how: * PYTHON_COMMAND is unset: pick the highest minor version of python3. Thanks Laszlo