RSB Deployment

[Chris Johns]

On 25/11/17 8:29 am, Jacob Saina wrote:
> Here's my new understanding -- stop me if I've got anything wrong.
> 
> (from <....>/rsb/rtems) Doing
> 
> ../source-builder/sb-set-builder  --without-kernel --jobs=none
> --prefix=/d/opt/rtems/4.11 4.11/rtems-arm
> 
> will build RSB (without the kernel, single threaded) in ./build, then install it
> at the prefix, which consists of copying the build to /d/opt/rtems/4.11. The
> install has: arm-rtems4.11, bin, include, lib, libexec, make, and share; which
> are the required pieces when deploying.

Correct.

> If --bset-tar-file were specified, then the build would be packaged into a tar
> file in addition to being installed at the prefix (unless --no-install were
> specified).

Correct.

> The tar file would contain paths that expect it to be installed at
> the specified prefix. To deploy, one would simply  copy this tar file and
> extract it (accounting for the file path prefix).

Yes from the root directory of the new machine. The idea is to capture the build
as a complete build. You could post process this file with a script of your own
to create tar or ZIP file that better suites your needs.

This is documented here:

https://docs.rtems.org/branches/master/rsb/quick-start.html#deployment

> --pkg-tar-files will generate tar files for individual packages (e.g. gcc,
> binutils). What's the use case for this?

The build set tar file option has all the packages in the build set in a single
image. This means the `bin` directory has binary files from a number of packages
and you cannot determine which file came from which package. The per package tar
file option lets you see the contents on a per package basis. For example if you
do not want autoconf and automake in your deployment package you can create a
temporary directory, change into it and then untar the packages you want and
then create a new tar or zip file with just those packages.

> Part of RSB is autoconf and automake, which are built with hardcoded file paths
> (the prefix). The environment itself does not need autoconf and automake to be
> installed (in the package manager sense) to build RSB. 

I would correct this last part to say "to build an RTEMS application".

> Autoconf and automake
> that are built as part of RSB are used to build the kernel.

Yes. This is the single reason those packages are in the RTEMS tools build set.

> One could specify a prefix that does not exist on computer A, but does exist on
> computer B, with --no-install and --bset-tar-file, and the resulting tar file
> could be installed at computer B's prefix.

Yes you can do this. :)

> Onto some responses:
> 
>     > 5) If I've built and installed everything, can I prepare that build for
>     > deployment without rebuilding the project?
> 
>     I am not sure what project means here. The tools built by the RSB and an
>     installed kernel can be deployed, ie copied. You can use the RSB tar command or
>     you can build on a specific machine under a prefix and zip or tar the prefix
>     tree of files.
>  
> I meant: if RSB is already built and installed without generating a tar file,
> will running the sb-set-builder with --bset-tar-file rebuild RSB, or just
> package the existing installation?

No, existing files under a prefix are not packaged into a tar file. The RSB does
not hold any state information. The RSB always runs from the beginning so we
know the result of the build is what has been asked for. The RSB does not
maintain the build results to verify the files under the prefix are correct and
if it did it would just package the build it has a copy of and not the installed
version, and to do this it would need to have some form of checking to know the
build it has is valid. This complex to do in a way that can be audited and proven.

If you know the files under the prefix are untouched you could zip them.

>     The standard bootstrap script can be used, it is just slower.
> 
> Is this the bootstrap script that comes in the kernel repository, referred to in
> the instructions that say:
> ./bootstrap -c && ./bootsrtap -p && <...>/source-builder/sb-bootstrap
> What would I replace the sb-bootstrap piece with, just "./bootsrtap"?

Correct.

>     Is the Windows path on both machines the same? Companies may want to standardise
>     the install path to make things simpler. 
> 
> No, this computer happens to have a small C partition and large D "Data"
> partition, and I need to deploy to computers with only the C partition. 

I now understand and this make sense.

>     Check the cygwin mount command and syntax for details on mounting with MSYS2.
> 
>     This means the MSYS2 shell's view of the installed files is not what you have on
>     the other machine. I suggest you have a look under the shell and see what is
>     different and see if you can make them the same, ie the mount command.
> 
> Thanks, mount looks promising, I'll look into it.

Excellent.

> In the RSB 4.11.2 documentation
> (https://docs.rtems.org/releases/rtems-docs-4.11.2/rsb.pdf) on p18, is the
> discussion of install paths and using tar --strip-components a separate issue
> from what we've been talking about with automake and autoconf?

Yes this option is about managing the tar file. The strip components option is
not well known and so I added it as a way to help users manage the tar files the
RSB creates. The option is about installing a tar file without repackaging it
and changing the install prefix.

Chris