[RTEMS Project] #4916: Canadian cross building not staging GCC

[RTEMS trac]

#4916: Canadian cross building not staging GCC
----------------------+---------------------
 Reporter:  hguerard  |       Owner:  (none)
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:
Component:  tool/rsb  |     Version:  6
 Severity:  normal    |  Resolution:
 Keywords:  cxc       |  Blocked By:
 Blocking:            |
----------------------+---------------------

Comment (by Chris Johns):

 > Because the build is marked as canadian_cross, it is not installed. Why
 is that?

 A Cxc build does not install the final built output under the prefix
 because the prefix you provide is for the host operating system the build
 is destined for and that prefix path may not be compatible with the host
 you are building on.

 I think there are two issues we need to consider:

 1. Why do some packages get installed when they should not?
 1. How does a Cxc package a build?

 I do not know why some packages are being installed. This seems like a bug
 to me. I do not test Cxc often so thank you for the report and feedback.
 Are you able to look into the reason they are getting installed?

 The [https://docs.rtems.org/branches/master/user/rsb/cross-canadian-
 cross.html#canadian-cross-building RSB Cxc documentation] gives us some
 hints on why. It also looks to be out of date.

 == Why the change in the patch?

 The patch you referenced forces not installing because it detects a Cxc
 build. The documentation asks you to provide `--no-install` so this is now
 automatic. At least the change is consistent. But why the change?

 I suspect the change was made because of the changes to support 3rd party
 packages and the complexity it adds to handling installs. I do not
 remember the specifics of the change so at a guess I must have seen an
 issue in the staging changes that conflicted with something in the
 handling of Cxc installs. It may have been as simple as Cxc adding extra
 states around installation and because it is best not to install a Cxc
 build because the prefix may cause issues I took the easy option and
 forced the "no install" setting on.

 The change to support staging was needed for a range of reasons and I did
 not want to rewrite the build support to handle all possible cases that
 existed so a pragmatic choice was made, automatically turn off Cxc
 installing.

 == How does a Cxc package a build?

 The documentation also provides the answer. It asks you to provide the
 `--bset-tar-files` option. Maybe that option should be forced on for Cxc
 builds? You need it on or a Cxc build will produce no output.

 When deploying Cxc builds you need to take the built output and package it
 somehow for the host you are deploying the tools on. A tar file provides a
 convenient portable means to capture the entire build in a single file. I
 prefer it over collecting the files under the prefix after installing.

 My [https://git.rtems.org/chrisj/rtems-deployment.git/ RTEMS Deployment]
 repo uses tar files for this purpose. The generated
 [https://git.rtems.org/chrisj/rtems-deployment.git/tree/pkg/rpm.spec.in
 Linux RPM spec file] uses the RSB to build a tar file of the RTEMS
 vertical stack and then simply places the tar file contents in the RPM.
 The process does not claim to make perfect packages but as a tool for
 deployment it works well. You can make deployable containers on Linux with
 the RTEMS tools and libraries controlled by an RPM, ie an RPM verify can
 check the install and an RPM query can report the version. If I was to add
 Windows install support to the deployment repo I would use an installer
 like NSIS that runs on Linux and do the same thing.

--
Ticket URL: <http://devel.rtems.org/ticket/4916#comment:1>
RTEMS Project <http://www.rtems.org/>
RTEMS Project