[PATCH 1/3] build: Format build items

[Chris Johns]

On 20/1/2023 11:53 am, Amar Takhar wrote:
> On 2023-01-20 11:03 +1100, Chris Johns wrote:
> 
>> I have been OK with the headers and tests being generated this way because the
>> agreement is files in rtems.git can be manually edited and rtems-central has to
>> track those changes. The sources and code to generate the files need to be
>> located together.
> 
> Yes.  To be clear in this case if we have <somefile.h> in rtems.git and 
> <somefile.yml> in rtems-central.git where you need to edit <somefile.yml> to 
> generate <somefile.h> then both the tool *and* somefile.yml need to be in 
> rtems.git.

Placing the API header spec files into rtems.git complicates being able to
update or add a new API by editing the header files. With the spec files to
generate the headers in the same repo they would need to be updated and that
means learning about the whole qual workflow, spec formats etc. This is why the
separation is done this way. As things are the rtems-central could be left as is
and rtems.git is not effected. We just continue to maintain the headers
manually. Those interested in qualifications can fund support for rtems-central
independently of the other parts of RTEMS.

> If what you are saying is the requirement is reversed.  rtems-central.git needs 
> rtems.git to work that's fine and the order it should be.

The rtems-central specs files are cleverly put together so the headers,
documentation and other pieces are all handled from one place. This means all
pieces would need to be brought together. The rtems-central repo is the central
clearing house for the specifications.

Chris