Most often, an application is organized into modules and submodules,
which are very conveniently represented as a project tree or graph
(the root project A withs the projects for each modules (say B and C),
which in turn with projects for submodules.
Very often, modules will build their own executables (for testing purposes for instance), or libraries (for easier reuse in various contexts).
However, if you build your project through gnatmake or gprbuild, using a syntax similar to
gprbuild -PA.gpr
this will only rebuild the main programs of project A, not those of the imported projects B and C. Therefore you have to spawn several gnatmake commands, one per project, to build all executables. This is a little inconvenient, but more importantly is inefficient because gnatmake needs to do duplicate work to ensure that sources are up-to-date, and cannot easily compile things in parallel when using the -j switch.
Also libraries are always rebuilt when building a project.
You could therefore define an aggregate project Agg that groups A, B and C. Then, when you build with
gprbuild -PAgg.gpr
this will build all mains from A, B and C.
aggregate project Agg is
for Project_Files use ("a.gpr", "b.gpr", "c.gpr");
end Agg;
If B or C do not define any main program (through their Main attribute), all their sources are built. When you do not group them in the aggregate project, only those sources that are needed by A will be built.
If you add a main to a project P not already explicitly referenced in the aggregate project, you will need to add "p.gpr" in the list of project files for the aggregate project, or the main will not be built when building the aggregate project.
Aggregate projects are only supported with gprbuild, but not with gnatmake.