11.11 Library Projects

Library projects are projects whose object code is placed in a library. (Note that this facility is not yet supported on all platforms)

To create a library project, you need to define in its project file two project-level attributes: Library_Name and Library_Dir. Additionally, you may define the library-related attributes Library_Kind, Library_Version, Library_Interface, Library_Auto_Init, Library_Options and Library_GCC.

The Library_Name attribute has a string value. There is no restriction on the name of a library. It is the responsability of the developer to choose a name that will be accepted by the platform. It is recommanded to choose names that could be Ada identifiers; such names are almost guaranteed to be acceptable on all platforms.

The Library_Dir attribute has a string value that designates the path (absolute or relative) of the directory where the library will reside. It must designate an existing directory, and this directory must be different from the project's object directory. It also needs to be writable.

If both Library_Name and Library_Dir are specified and are legal, then the project file defines a library project. The optional library-related attributes are checked only for such project files.

The Library_Kind attribute has a string value that must be one of the following (case insensitive): "static", "dynamic" or "relocatable". If this attribute is not specified, the library is a static library, that is an archive of object files that can be potentially linked into an static executable. Otherwise, the library may be dynamic or relocatable, that is a library that is loaded only at the start of execution. Depending on the operating system, there may or may not be a distinction between dynamic and relocatable libraries. For Unix and VMS Unix there is no such distinction.

If you need to build both a static and a dynamic library, you should use two different object directories, since in some cases some extra code needs to be generated for the latter. For such cases, it is recommended to either use two different project files, or a single one which uses external variables to indicate what kind of library should be build.

The Library_Version attribute has a string value whose interpretation is platform dependent. It has no effect on VMS and Windows. On Unix, it is used only for dynamic/relocatable libraries as the internal name of the library (the "soname"). If the library file name (built from the Library_Name) is different from the Library_Version, then the library file will be a symbolic link to the actual file whose name will be Library_Version.

Example (on Unix):

     project Plib is
     
        Version := "1";
     
        for Library_Dir use "lib_dir";
        for Library_Name use "dummy";
        for Library_Kind use "relocatable";
        for Library_Version use "libdummy.so." & Version;
     
     end Plib;

Directory lib_dir will contain the internal library file whose name will be libdummy.so.1, and libdummy.so will be a symbolic link to libdummy.so.1.

When gnatmake detects that a project file is a library project file, it will check all immediate sources of the project and rebuild the library if any of the sources have been recompiled.

When a library is built or rebuilt, an attempt is made to delete all files in the library directory. All ALI files will also be copied from the object directory to the library directory. To build executables, gnatmake will use the library rather than the individual object files. The copy of the ALI files are made read-only.