This section describes what the projects are, and what information they contain.
The most important thing to note is that the projects used by GPS are the same as the ones used by GNAT. These are text files (using the extension .gpr) which can be edited either manually, with any text editor, or through the more advanced GPS interface.
The exact syntax of the project files is fully described in the GNAT User's Guide (gnat_ug.html) and GNAT Reference Manual (gnat_rm.html). This is recommended reading if you want to use some of the more advanced capabilities of project files which are not yet supported by the graphical interface.
GPS can load any project file, even those that you have been edited manually. Furthermore, you can manually edit project files created by GPS.
Typically you will not need to edit project files manually, since several graphical tools such as the project wizard (The Project Wizard) and the properties editor(The Project Properties Editor) are provided.
GPS doesn't preserve the layout nor comments of manually created projects after you have edited them in GPS. For instance, multiple case statements in the project will be coalesced into a single case statement. This normalization is required for GPS to be able to preserve the previous semantic of the project in addition to the new settings.
All command-line GNAT tools are project aware, meaning that the notion of project goes well beyond GPS' user interface. Most capabilities of project files can be accessed without using GPS itself, making project files very attractive.
GPS uses the same mechanisms to locate project files as GNAT itself:
Project files contain all the information that describe the organization of your source files, object files and executables.
A project file can contain comments, which have the same format as in Ada, that is they start by "–" and extend to the end of the line. You can add comments when you edit the project file manually. GPS will attempt to preserve them when you save the project through the menu, but this will not always be possible. It helps if the comments are put at the end of the line, as in
project Default is
for Source_Dirs use (); -- No source in this project
end Default;
Generally, one project file will not be enough to describe a complex organization. In this case, you will create and use a project hierarchy, with a root project importing other sub projects. Each of the projects and sub projects is responsible for its own set of sources (compiling them with the appropriate switches, put the resulting files in the right directories, ...).
Each project contains the following information (see the GNAT user's guide for the full list)
If one of the source files of project A depends on some source files from project B, then B must be imported by A. If this isn't the case, the compiler will complain that some of the source files cannot be found.
One important rule is that each source file name must be unique in the project hierarchy (i.e. a file cannot be under control of two different projects). This ensures that the same file will be found no matter what project is managing the source file that uses
When sources from imported sub-projects are recompiled, the resulting object files are put in the sub project's own object directory, and will never pollute the parent's object directory.
The default to find this set of source files is to take all the files in the source directories that follow the naming scheme (see below) for each language. In addition if you edit the project file manually, it is possible to provide an explicit list of source files.
This attribute cannot be modified graphically yet.
The name of the file is generally related to the name of the executable.
A given project file hierarchy can be used to compile and link several executables. GPS will automatically update the Compile, Run and Debug menu with the list of executables, based on this list.
GPS also supports embedded targets (VxWorks, ...) by specifying alternate names for the build and debug tools.
The project file contains the information required to log on the remote host.