[PATCH 1/3] build: Format build items

[Amar Takhar]

On 2023-01-20 11:03 +1100, Chris Johns wrote:
<snip> 
> It is good to know the amount of python is small. It should be easy to add :)

Agreed.


> 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.

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 specification maintenance is a separate responsibility to the function and
> role of rtems.git and related repos. The bar to make changes in rtems.git is at
> the source level because it is the norm for open source projects and those
> working with the code. The separation also helps make it clear how funding of
> the qual related work happens. If we bring those specifications items down into
> rtems.git the responsibility moves to that repo and that raises the bar on being
> able to make a change. Our view on this may change as we learn now the pre-qual
> effort effects what we do.

I think the important part here is it's evolving.  Change happens sometimes you 
do one thing one way to discover you really want or need to do it another.


> We have YAML files to run our build system and it is awesome. It also allows
> automation so I think it makes sense to provide an interface to read and write
> these files to aid automation rather than a disjointed set of personal scripts,
> tools etc that may break or clash.

Agreed on this.


> The FreeBSD single repo is about the kernel and base runtime. The ports are not
> part of this so the analogy breaks down. Bringing the RSB, RTEMS tools and
> documentation into a single repo creates new complexities I am not sure we are
> prepared enough to handle those. Maybe patch review and CI would help here and
> how they effect a single repo is something I have not given much consideration too.

In theory I'm not against bringing everything together into one repository it 
allows for a lot of inter connectivity we can't do right now.  Regardless even 
if we had been doing it this way I would still advocate for the change being in 
the /rtems/ directory versus /rtems-central/


Amar.