RSB

Chris Johns chrisj at rtems.org
Thu Sep 16 00:08:40 UTC 2021


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.

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

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

> 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


More information about the devel mailing list