RSB

[Joel Sherrill]

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:
> >>> On Mon, Sep 13, 2021, 7:02 PM Joel Sherrill <joel at rtems.org
> >>> <mailto:joel at rtems.org>> wrote:
> >>>     On Mon, Sep 13, 2021 at 6:54 PM Chris Johns <chrisj at rtems.org
> >>>     <mailto:chrisj at rtems.org>> wrote:
> >>>     > On 13/9/21 11:20 pm, Joel Sherrill wrote:
> >>>     > > Hi
> >>>     > >
> >>>     > > If building a bset tar file, does it matter if the installation prefix
> >>>     > > is writable?
> >>>     > >
> >>>     > > ../source-builder/sb-set-builder --bset-tar-file --log=l-i386.txt
> >>>     > > --prefix=/rtems/tools 5/rtems-i386
> >>>     > > RTEMS Source Builder - Set Builder, 5 (c7870f6e6199)
> >>>     > > error: prefix is not writable: /rtems/tools
> >>>     > >
> >>>     > > It does if you are planning to immediately install but if building for
> >>>     > > later installation, I don't think it matters.
> >>>     > >
> >>>     > > Thoughts?
> >>>     >
> >>>     > What happens if you add --no-install?
> >>>
> >>>     It skips the test.
> >>>
> >>> And doesn't install anything.
> >>
> >> Excellent.
> >>
> >>>     > If this does help the question moves to if making a bset is packaging
> >>>     around an
> >>>     > install or is it the only output option?
> >>>
> >>>     With a bset-tar, I don't think it did an install anyway. But it's been
> >>>     a long day. I can
> >>>     check again tomorrow if you want me to.
> >>>
> >>> Builds and installs tools unless you specify no install.
> >>>
> >>> Tar files is an additive behavior.
> >>
> >> OK and thanks
> >>
> >>> I am off today but will try to review the help and user docs to make sure this
> >>> is clear.
> >>>
> >>> Any thoughts on the tools tarballs not having the architecture name in it? If
> >>> you build multiple architectures or just want to maintain tool tarballs for
> >>> multiple architectures, you have to manually rename them.
> >>
> >> Could you please remind me about the naming and then what you would like?
> >
> > After building tools for ARM for RTEMS 5, this is what is in the tar/
> > directory.
> >
> > + ls -1 tar
> > automake-1.12.6-x86_64-linux-gnu-1.tar.bz2
> > rtems-tools-0a5d2057749066e7d184836e92c7ce5334fccc90-1.tar.bz2
> >
> > I wondered where autoconf was and it is in the automake tarball. Either
> > autoconf should be in a separate tarball of the tarfile should be autotools
> > like is used in the bsets. Not sure which but just saying automake-1.12.6
> > and including autoconf is not right.
>
> It would seem the tar name is not the parent bset.

Yes.

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

The automake tarball has automake and autoconf

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.

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

I can send you lists of what is in each tarball if you like.

>
> > One thing I also noticed which might cause problems with people feeding
> > the tools tarball into another packaging system is that there are duplicate
> > files across architectures.
>
> Yeap.

This is just an observation but isn't a problem for us. The tarfile
names and contents
not aligning is the problem.

>
> > I don't see the RSB addressing this but someone
> > creating RPM, deb, etc packages might have to.
>
> Correct.
>
> > If post processing
> > is needed to break out a rtems-tools-common tarball, that is on someone
> > feeding these into something that doesn't like duplicate files in packages.
> >
> > So.. (1) automake has autoconf also and (2) same name is used for rtems-tools
> > independent of architecture.
>
> Packaging is beyond the RSB. You have highlighted a couple of issues and more
> exist. For example in each build of gcc there are common host files and there
> are common host independent files. To map multiple builds of tools into a
> packaging system you need to identify all common pieces and then group them
> based on the packaging system requirements. You then create a package dependency
> tree for the generated packages.
>
> Chris