[PATCH 1/3] build: Format build items

Chris Johns chrisj at rtems.org
Thu Jan 19 00:05:33 UTC 2023


On 19/1/2023 8:58 am, Amar Takhar wrote:
> On 2023-01-17 08:39 +0100, Sebastian Huber wrote:
> <snip>
>>
>> The Python modules to work with specification items are in 
>> rtems-central.git. This repository contains also a format specification 
>> of the build items. We could add an action to a Github work flow to 
>> check the build item format for pull requests and commits.
> 
> I don't chime in here very often but after seeing the recent changes I'm 
> extremely confused.
> 
> There are now tools that sit outside of the RTEMS repository that now change 
> source files in RTEMS?
> 
> I have never seen it done this way before.  What version of this tool have you 
> used?  How can anyone in the future possibly debug this?
> 
> What should happen here is this tools should sit in the main repository.  Any 
> required changes made and then a command run to generate new output:
> 
>   ./waf <somecommand>
> 
> This lets us know that the output in this commit was generated by code existing 
> in the previous commit.  There is no need to version anything it's already done.
> 
> Having it sitting outside of the source repository makes debugging impossible.  
> Case in point is the commit message here.  No explanation as to where these 
> changes have come from.  No commit version.  I spent a very long time figuring 
> out what was going on and I could not figure it out without digging through the 
> lists.
> 
> How is anyone in 5, 10, 15 years down the road going to sort through this?  What 
> if I want to make a change in 10 years and regenerate.  It is impossible as I 
> have no idea what's been done let alone where to look.
> 
> I'm not against the purpose of the tool or the work has been done but this is 
> not the correct way to handle generated files within a repository if we want to 
> maintain the ability to make changes or debug years down the line.

Yes these are good points. The rtems-central repo is not a requirement for
rtems.git and never will be. The separation was agreed to before any qual work
started. The rtems.git repo can exist and operate without rtems-central however
the rtems-central repo is meaningless without rtems.git so Amar I agree the
dependency is the wrong way around.

I have agreed to generated content for headers, some tests, and documentation
because the generator input is in rtems-central so the effort to maintain that
rtems-central data with any manual changes in rtems.git etc is part of the
overhead of maintaining rtems-central. The build spec files are in rtems.git and
this relationship is very different.

Chris


More information about the devel mailing list