RSB Deployment

[Jacob Saina]

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.

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

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

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.
Autoconf and automake that are built as part of RSB are used to build the
kernel.

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.


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?



> 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"?


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.

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.


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?


Thanks,
Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20171124/22f80560/attachment-0002.html>