[PATCH] GDB: fix python config command line arguments based on python version

[Chris Johns]

On 22/4/22 11:18 pm, Frank Kühndel wrote:
> Hi Chris,
> 
> On 4/22/22 03:19, Chris Johns wrote:
>> On 21/4/2022 5:45 pm, Karel Gardas wrote:
>>> On 4/21/22 02:12, Chris Johns wrote:
>>>> On 21/4/2022 4:38 am, Karel Gardas wrote:
>>>>> Chris, Frank,
>>>>>
>>>>> I don't feel particularly comfortable with this patch. It works here on Ubuntu
>>>>> 20.04 with python 3.3 and Ubuntu 22.04 with Python 3.10, but I have to admit
>>>>> semantics of this cfg language is beyond my liking and a lot is in complete
>>>>> darkness here. E.g. how &&, < operator are working here. Delete both int
>>>>> conversions and it'll not work at all. Keep one and it'll work well.
>>>>> The problem is probably lack of time to go thorough all the docs on
>>>>> docs.rtems.org to find relevant bits while working on the patch.
>>>>>
>>>>> Anyway, if you have time, please review and test on your platforms.
>>>> I think you are right to be concerned. I cannot find in the parser any support
>>>> for `int()` which makes me wonder if `int(3)` is being compared but I am not
>>>> sure.
>>> Hmm. And I've thought cfg format is just DSL interpreted in python hence
>>> translated internally to python hence my int() usage.
>>>
>>>> Leave this with me and I will take a closer look.
>>> Absolutely!
>>>
>>>> I think we will need to add a
>>>> numerical compare. Hmmm.
>>> Another solution may be to enhance version string to print every number with two
>>> digits and with leading zero if needed and concatenate string together. This may
>>> probably work too even with lexi comparison.
>>> E.g.
>>>
>>> 2.7.1  -> "020701"
>>> 2.7.17 -> "020717"
>>> 3.9.2  -> "030902"
>>> 3.10.3 -> "031003"
>>>
>>> Hard to judge which approach is cleanest one.
>> This breaks when we exceed 99 etc. Maybe that will happen, maybe it will not.
> 
>> I wonder if hacking the parser to handle this provides a more long term solution
>> beyond this use case.
>>
>> The problem becomes adding support to the language. I wonder if checking if both
>> the left and right hand sides in a compare are numeric, ie 3 or 3.0, and if they
>> are make the comparison numeric? To force a lexicographical comparison simply
>> have `%if x%{yyy} < 3.8`?
> 
> Do not exists simpler solutions than changing the language?

The language is not changing, rather the ability to check numbers is supported
and I think that is a good change.

> For example, calling `/usr/bin/python3-config --help` first. If the
> result string contains `--embed` use it, else don't.
> 
> For example on OpenSUSE (Python 3.6.15):
> 
> $  /usr/bin/python3-config --help
> Usage: /usr/bin/python3-config
> --prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--extension-suffix|--help|--abiflags|--configdir
> 
> On Fedora 35 (Python 3.10.4):
> 
> $ /usr/bin/python3-config --help
> Usage: /usr/bin/python3.10-x86_64-config
> --prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--extension-suffix|--help|--abiflags|--configdir|--embed
> 
> Again OpenSUSE but Python 2.7.18:
> 
> $ /usr/bin/python2-config --help
> Usage: /usr/bin/python2-config
> [--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--help]
> 
> For example, the following command will either return "--embed" or empty
> (the redirection of strerr is important for Python 2):
> 
> $ /usr/bin/python3-config --help 2>1 | grep --fixed-strings
> --only-matching -e --embed

Yes we could do this but I think the change I have posted is still good to have.

Chris