Requirements
- For Linux, prefer to derive automatically from Flight Software release
- Produce identically-structured installed form on all supported operating systems
- Has to support dynamic loading of certain shareables by flight software code. These shareables may have duplicate names.
- Minimize link time and complexity for applications linked against obf
- Minimize distributed size
Release Build vs. Installation
The current organization of the obf external library is identical to that used by Flight Software. This is a necessary stage in producing an installed version, but there are drawbacks to using it as the installed version.
The fsw external library (or, rather, the procedure - hereinafter called "the script" - which produces it) uses the flight software build as a starting point but copies only files which are needed to build applications against the library, and changes the organization to simplify linking by putting all shareables in a single lib directory. This won't quite work for obf because of the (small number of) shareables with duplicate names, but the idea is to produce something very similar for obf from a full (flight software-style organization) build of needed packages. So, roughly the procedure on Linux would be
- run enhanced version of the script used now to produce the fsw external library. Its inputs would be, approximately
- list of packages of interest producing "regular" libraries
- list of packages of interest producing libraries which may be dynamically loaded
- pointer to flight software release build
On any other OS
- create build with organization identical to flight software release builds
- run script as above (ideally the identical script) but last input would be pointer to the created build
To do
- Determine what file organization is required by Flight Software to dynamically load libraries. Is it identical to release build organization?
- Upgrade script now used to generate the fsw external. Bryson is willing to look into this.