RSB

[Joel Sherrill]

On Thu, Sep 16, 2021, 6:36 PM Chris Johns <chrisj at rtems.org> wrote:

> On 16/9/21 10:59 pm, Joel Sherrill wrote:
> > On Wed, Sep 15, 2021 at 7:08 PM Chris Johns <chrisj at rtems.org> wrote:
> >> On 16/9/21 1:46 am, Joel Sherrill wrote:
> >>> On Tue, Sep 14, 2021 at 5:52 PM Chris Johns <chrisj at rtems.org> wrote:
> >>>> On 15/9/21 4:49 am, Joel Sherrill wrote:
> >>> The issue I mentioned is that the same rtems-tools- at TAG@-1.tar.bz2
> >>> is used for every architecture. Perhaps rtems-tools- at ARCH@- at TAG@
> -1.tar.bz2.
> >>> Then you can script building all architectures without renaming files.
> >>
> >> That implies the tools are arch specific and they are not. The tools
> should be
> >> tagged with the host arch details if we add anything.
> >
> > The issue is that the tarball name is wrong and the rtems-tools one
> rtems-tools,
> > binutils, gcc/newlib, and gdb. It includes EVERYTHING that is built
> > when you use 6/rtems-arm.
>
> I am not surprised, maybe the staging changes may have effected the tar
> naming?
>
> If you wanted to select a parent which parent would be selected?
>

I don't mind everything being lumped together. Except for rtems-tools, it
is all an arm RTEMS tool chain which is why it never struck me that it was
using the repo rtems-tools as the name.

Maybe rtems-toolchain-CPU. Ideally rtems-tools would be separate.

Maybe a variable to define the package name to override some default.

>
> The current design packages at the config file level it gives you the
> various
> pieces as a single block so you can packages them. A single tarball for
> the top
> level would make it hard for someone to use to make packages that can be
> deployed.
>
> For tools the name of the tarball needs to match the contents and it is
> native.
> The fact each arch bset builds the same thing is a side effect of the
> packaging
> being used. Adding the arch might create the impression each arch tools
> package
> has to be kept separate.
>
> > The automake tarball has automake and autoconf
>
> I am not sure why this is happening. Maybe 2 tarballs should be created.
> This
> stuff is a little more complicated because of the internal build stage.
> Autoconf
> and automake cannot be cleanly relocated so in installers I have created
> in the
> past I had the installer build the packages using the install prefix.
>

This one isn't critical as we aren't using it going forward. This is an
issue on 5 and older.



> > The rtems-tools tarball has everything I listed above. Beyond
> > rtems-tools, binutils,
> > gcc/newlib, and gdb, I suppose it also includes sis or dtc on some
> > architectures.
>
> Do you want the RSB to generate user accessible tar files that need no
> further
> touching?
>

Ideally they shouldn't be named the same. I don't particularly care if they
duplicate files. Packages would be nice not to duplicate since we should be
able to control that.

I'm already post processing to extract a common tarball. But the names and
contents of the RSB generated tarballs don't accurately reflect the
contents and don't reflect the target CPU (or host).

>
> > If it used the name from the top level bset it might be ok. Then you
> would have
> > autotools and something derived from 6/rtems-arm
>
> Yeap.
>
> > I can send you lists of what is in each tarball if you like.
>
> No need, I have an OK idea of what is contained in the packages


> Ok


>
>
> Chris
>