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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel