[PATCH 2/3] build: Replace variant patterns with a list

[Chris Johns]

On 19/1/2023 6:06 pm, Sebastian Huber wrote:
> On 19.01.23 01:17, Chris Johns wrote:
>>>> Why has this been done?
>>> The enabled-by expressions used in patch 3 do not support regular expressions.
>> I did not pick that up. Why was that regx functionality removed? Is it related
>> to scripting and rtems-central?
> 
> The enabled-by expressions supported by the wscript don't support regular
> expressions:
> 
> https://github.com/RTEMS/rtems/blob/master/wscript#L144
> 
> The interesting part of the patch set is patch 3:
> 
> Merge the "default" and "default-by-variant" attributes.  Use an
> "enabled-by" expression to select the default value based on the enabled
> set.  This makes it possible to select default values depending on other
> options.  For example you could choose memory settings based on whether
> RTEMS_SMP is enabled or disabled.

Thanks, this make sense. I had not made the connections.

>>>> Why the noise in the patch of only lines being moved? Where has this come from?
>>>> Is there a new requirement spec fields be in some osrt of order?
>>> I did the change with a script which sorted the lists. In general, the lists
>>> should be sorted.
>> This is a good example of problems a lack of scripting support along side the
>> build spec files creates. It makes manual changes difficult when rules get
>> layered like this plus it means you are the only one who can make generated
>> changes without there being a clash of scripting specifics, ie my script vs your
>> script or something like that.
> 
> I don't understand what is the problem with the sorted lists. If you have a list
> of unordered phrases, it is not unusual to still sort them in lexicographic order.

I welcome sorted entries. Manual edits may or may not be sorted so we end up
with a mix and when a "magic" script runs again it generates more of these white
space changes. If I can run:

./waf formatspec

the "magic" happens it is easy to document and for any user to update these
files, run a command and know the results are OK to post. It is no different to
the work Gedare is doing to get the code formatting sorted so none us have to
audit formatting of the code.

So let me turn this around ... I am do not understand your resistance to there
being importable modules of python in rtems.git to read and write these files in
rtems.git?

>> And I have no intention in cloning rtems-central and learning how to use it.
>> There was a primary agreement for the separation of all qual work and the
>> ability for it to be removed from the project without any side effects.
> 
> You don't have to use the stuff in rtems-central, it could be just more
> convenient and efficient. It would be possible to write a Github action which
> checks that the build items match the expected format for pull requests.

Lets not bring more github stuff into our workflows. There is no agreement that
github is what this project wants to use. I am OK with automation if it is
something we can manage.

Chris