[PATCH 1/3] build: Format build items

[Chris Johns]

On 20/1/2023 11:22 am, Karel Gardas wrote:
> 
> Sorry to hijack that thread, but correction is needed here.
> 
> On 1/20/23 01:03, Chris Johns wrote:
>> The FreeBSD single repo is about the kernel and base runtime. The ports are not
>> part of this so the analogy breaks down.
> 
> Certainly all BSDs have separated ports repos, but AFAIK all of them maintain so
> called base and in base there is kernel, libs, bin/sbin commands and most
> importantly *all* tool-chain required to build *all* this code to form whole OS.

Yes the ports place executables in /usr/local. The kernel and base is considered
a working set so the user commands under /bin /usr/bin /sbin etc match the
kernel and it is tested as a whole.

We will never have a single repo of all sources such as gcc etc like FreeBSD has.

> IMHO this rebuild whole OS distro is discussed here, isn't it? If not, I'm sorry
> for noise here...

Ah ok, the discussion is about the how we manage over a long period of time
scripts, tools etc that read and write the spec files in rtems.git. This patch
adds a format option to aid automation via scripting however there is no script
support included so is that left as an exercise for those in the know on how to
do it or should we require support being brought into rtems.git and maintained
along with the file format? If there is no provided scripting support who does
this patch serve or benefit and what value does it bring other than overheads in
maintaining these spec files? [1]

The spec files are close or the same as the YAML spec files rtems-central has
and that repo has scripting support so those working with rtems-central are ok
because that single repo has consistent support. The history and agreement for
the qual effort is these repos remain separated and nothing has changed here.
The rtems.git repo will always take precedence over rtems-central.git.

In relation to a single RTEMS repo it helps make deployment easier for some use
cases and for others it makes no difference. It all depends on how you want to
tool up for deployment but it is not essential. Many repos or a single repo does
not change what is in a release and that is where the project's efforts are focused.

Chris

[1] the patch in this thread was pushed while I am still questioning it (hmm)