This chapter describes GNAT's Project Manager, a facility that allows
you to manage complex builds involving a number of source files, directories,
and options for different system configurations. In particular,
project files allow you to specify:
- The directory or set of directories containing the source files, and/or the
names of the specific source files themselves
- The directory in which the compiler's output
(ALI files, object files, tree files, etc.) is to be placed
- The directory in which the executable programs are to be placed
- ^Switch^Switch^ settings for any of the project-enabled tools;
you can apply these settings either globally or to individual compilation units.
- The source files containing the main subprogram(s) to be built
- The source programming language(s)
- Source file naming conventions; you can specify these either globally or for
individual compilation units (see Naming Schemes).
- Change any of the above settings depending on external values, thus enabling
the reuse of the projects in various scenarios (see Scenarios in Projects).
- Automatically build libraries as part of the build process
(see Library Projects).
Project files are written in a syntax close to that of Ada, using familiar
notions such as packages, context clauses, declarations, default values,
assignments, and inheritance (see Project File Reference).
Project files can be built hierarchically from other project files, simplifying
complex system integration and project reuse (see Organizing Projects into Subsystems).
- One project can import other projects containing needed source files.
More generally, the Project Manager lets you structure large development
efforts into hierarchical subsystems, where build decisions are delegated
to the subsystem level, and thus different compilation environments
(^switch^switch^ settings) used for different subsystems.
- You can organize GNAT projects in a hierarchy: a child project
can extend a parent project, inheriting the parent's source files and
optionally overriding any of them with alternative versions
(see Project Extension).
Several tools support project files, generally in addition to specifying
the information on the command line itself). They share common switches
to control the loading of the project (in particular
The Project Manager supports a wide range of development strategies,
for systems of all sizes. Here are some typical practices that are
- Using a common set of source files and generating object files in different
directories via different ^switch^switch^ settings. It can be used for instance, for
generating separate sets of object files for debugging and for production.
- Using a mostly-shared set of source files with different versions of
some units or subunits. It can be used for instance, for grouping and hiding
all OS dependencies in a small number of implementation units.
Project files can be used to achieve some of the effects of a source
versioning system (for example, defining separate projects for
the different sets of sources that comprise different releases) but the
Project Manager is independent of any source configuration management tool
that might be used by the developers.
The various sections below introduce the different concepts related to
projects. Each section starts with examples and use cases, and then goes into
the details of related project file capabilities.