11.1 Introduction

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 ^-P^/PROJECT_FILE=^projectfile and ^-X^/EXTERNAL_REFERENCE=^vbl=value).

The Project Manager supports a wide range of development strategies, for systems of all sizes. Here are some typical practices that are easily handled:

• 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.