Re: [PATCH 1/1] edksetup.sh: rework python executable scanning

["Laszlo Ersek" <lersek@redhat.com>]

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 <liming.gao@intel.com>; Leif Lindholm <leif.lindholm@linaro.org>
>> Cc: devel@edk2.groups.io; Rebecca Cran <rebecca@bsdio.com>; Feng, Bob C <bob.c.feng@intel.com>; Kinney, Michael D
>> <michael.d.kinney@intel.com>; 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 <lersek@redhat.com>
>>>> Cc: devel@edk2.groups.io; Rebecca Cran <rebecca@bsdio.com>; Feng, Bob C <bob.c.feng@intel.com>; Gao, Liming
>>>> <liming.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; 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