Previous: Sharing Between Projects, Up: Organizing Projects into Subsystems [Contents][Index]
We have already seen many examples of attributes used to specify a special option of one of the tools involved in the build process. Most of those attributes are project specific. That it to say, they only affect the invocation of tools on the sources of the project where they are defined.
There are a few additional attributes that apply to all projects in a hierarchy as long as they are defined on the "main" project. The main project is the project explicitly mentioned on the command-line. The project hierarchy is the "with"-closure of the main project.
Here is a list of commonly used global attributes:
This attribute points to a file that contains configuration pragmas
to use when building executables. These pragmas apply for all
executables build from this project hierarchy. As we have seen before,
additional pragmas can be specified on a per-project basis by setting the
Compiler.Local_Configuration_Pragmas
attribute.
This attribute is a list of compiler switches to use when compiling any
source file in the project hierarchy. These switches are used in addition
to the ones defined in the Compiler
package, which only apply to
the sources of the corresponding project. This attribute is indexed on
the name of the language.
Using such global capabilities is convenient. It can also lead to unexpected behavior. Especially when several subsystems are shared among different main projects and the different global attributes are not compatible. Note that using aggregate projects can be a safer and more powerful replacement to global attributes.