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 12:43:13 -0700 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9F486300CA3B; Wed, 17 Jul 2019 19:43:12 +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 B79C7600D1; Wed, 17 Jul 2019 19:43:10 +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> <6d14f24e-34ed-ea7f-3921-9c09604a9628@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E4A9EF5@SHSMSX104.ccr.corp.intel.com> From: "Laszlo Ersek" Message-ID: <722290ee-15a1-780b-5027-6dd4058587f8@redhat.com> Date: Wed, 17 Jul 2019 21:43:09 +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: <4A89E2EF3DFEDB4C8BFDE51014F606A14E4A9EF5@SHSMSX104.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Wed, 17 Jul 2019 19:43:12 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 07/17/19 16:32, Gao, Liming wrote: > Laszlo: > >> -----Original Message----- >> From: Laszlo Ersek [mailto:lersek@redhat.com] >> Sent: Wednesday, July 17, 2019 6:22 PM >> To: Gao, Liming ; Leif Lindholm >> Cc: devel@edk2.groups.io; Rebecca Cran ; Feng, Bob C ; Kinney, Michael D >> ; afish@apple.com >> Subject: Re: [PATCH 1/1] edksetup.sh: rework python executable scanning >> >> 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. > Correct one typo here, sorry for the confuse. > If it is set to other value, edksetup.sh will find Python2 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. > > Before Python3 enable, there is no requirement to set PYTHON_COMMAND path. > To keep this support, introduce PYTHON3_ENABLE for auto find python2 or python3. Ah, I see, PYTHON3_EANBLE is itself a compat knob. Thanks, Laszlo