Distributing Ada Libraries

Product Family: SCORE
Target CPU: 1750A
Language: Ada
Host: PC/Windows

Many software projects are built from components provided by different teams. In many cases these teams are within the same company, but often multiple companies work together to produce the end result. It is usually desirable to send all of the source code to the final integration team to ease debugging. However, it may not be desirable to share the source code with other companies who only need a particular component to be linked in and then operate as a black box. Even when supplying source code, it is often desirable to provide the object code to ensure that the component is built with the correct options, and the tested version is integrated. SCORE provides facilities to support any of these models.

With SCORE Ada 95 it is very simple to distribute Ada libraries between multiple groups. SCORE's approach to Ada libraries does not involve a built-in hierarchy where one library must be built on top of another library. Instead each library is standalone, and the order the libraries are processed is determined by the order they are specified called the Ada path. This means that different teams can create Ada libraries containing the code for mission planning software, flight controls, 1553/Fibrechannel interfaces, etc. The Ada library and an interface document are all that need to be supplied to another group.

There are a couple of restrictions to keep in mind when distributing Ada libraries. The first is that the source code will not be available for debugging. If the source code is additionally provided, then the user can issue commands to the debugger to map the location of where the source was installed with the location from which it was originally compiled. This eliminates the need for other groups to integrate source code/build scripts with their own development structure, and alleviates concerns about getting different compilation orders, inline dependencies, and other issues which could produce a version that does not match the officially validated software. If the source is not provided, then the debugger will simply report that source is not available for those routines, and any debugging would be at the machine level. When the debugger encountered source which was present, then it would revert to source level debugging.

The second restriction is that each team must be using the same version of SCORE. When an Ada library is distributed it will contain dependencies on a certain version of the root library (ie. Package System), from the Ada path in use at the time it was built. When this library is inserted into another Ada path, then it must have the same version of the root library in order for these dependencies to not be invalidated.

The third issue is that the code should be compiled with the -norecompile option. This option informs the SCORE tools, that these compilation units should not be considered for recompilation. Without this option, the SCORE tools would attempt to check the timestamp of the compilation unit in the Ada library with the source file used to build it. When the file is not found, it will issue a warning about the missing file. When -norecompile was specified, the SCORE tools will assume these compilation units are always up to date, and will not look for their source files which may not be present. As long as all of the dependencies on the units can be validated (ie same version of dependent libraries specified in the Ada path), then the build will be successful.

Following a couple of very simple guidelines, SCORE provides a very flexible yet simple approach to Ada libraries.