Ada programs are usually easier to build than programs written in other languages like C or C++, which frequently require a makefile. This is because an Ada source file already specifies the dependencies of its source unit. See the with keyword for further details.
Building an Ada program is not defined by the Reference Manual, so this process is absolutely dependent on the compiler. Usually the compiler kit includes a make tool which compiles a main program and all its dependencies, and links an executable file.
Building with various compilersEdit
- This list is incomplete. You can help Wikibooks by adding the build information for other compilers.
With GNAT, you can run this command:
gnat make <your_unit_file>
If the file contains a procedure, gnatmake will generate an executable file with the procedure as main program. Otherwise, e.g. a package, gnatmake will compile the unit and all its dependencies.
GNAT command lineEdit
gnatmake can be written as one word
gnatmake or two words
gnat make. For a full list of gnat commands just type
gnat without any command options. The output will look something like this:
GNAT 3.4.3 Copyright 1996-2004 Free Software Foundation, Inc. List of available commands GNAT BIND gnatbind GNAT CHOP gnatchop GNAT CLEAN gnatclean GNAT COMPILE gnatmake -c -f -u GNAT ELIM gnatelim GNAT FIND gnatfind GNAT KRUNCH gnatkr GNAT LINK gnatlink GNAT LIST gnatls GNAT MAKE gnatmake GNAT NAME gnatname GNAT PREPROCESS gnatprep GNAT PRETTY gnatpp GNAT STUB gnatstub GNAT XREF gnatxref Commands FIND, LIST, PRETTY, STUB and XREF accept project file switches -vPx, -Pprj and -Xnam=val
For further help on the option just type the command (one word or two words — as you like) without any command options.
Vim Ada Mode is maintained by The GNU Ada project.
GNAT with XcodeEdit
Apple's free (gratis) IDE, Xcode, uses the LLVM compiler with the Clang front-end, and does not support Ada: however, in Xcode 4.3 for OS X Lion and later versions, the command line tools (assembler, linker etc) which are required to use GNAT are an optional component of Xcode and must be specially installed.
Rational APEX is a complete development environment comprising a language sensitive editor, compiler, debugger, coverage analyser, configuration management and much more. You normally work with APEX running a GUI.
APEX has been built for the development of big programs. Therefore the basic entity of APEX is a subsystem, a directory with certain traits recognized by APEX. All Ada compilation units have to reside in subsystems.
You can define an export set, i.e. the set of Ada units visible to other subsystems. However for a subsystem A to gain visibility to another subsystem B, A has to import B. After importing, A sees all units in B's export set. (This is much like the with-clauses, but here visibility means only potential visibility for Ada: units to be actually visible must be mentioned in a with-clause of course; units not in the export set cannot be used in with-clauses of Ada units in external subsystems.)
Normally subsystems should be hierarchically ordered, i.e. form a directed graph. But for special uses, subsystems can also mutually import one another.
For configuration management, a subsystem is decomposed in views, subdirectories of the subsystem. Views hold different development versions of the Ada units. So actually it's not subsystems which import other subsystems, rather subsystem views import views of other subsystems. (Of course, the closure of all imports must be consistent — it cannot be the case that e.g. subsystem (A, view A1) imports subsystems (B, B1) and (C, C1), whereas (B, B1) imports (C, C2)).
A view can be defined to be the development view. Other views then hold releases at different stages.
Each Ada compilation unit has to reside in a file of its own. When compiling an Ada unit, the compiler follows the with-clauses. If a unit is not found within the subsystem holding the compile, the compiler searches the import list (only the direct imports are considered, not the closure).
Units can be taken under version control. In each subsystem, a set of histories can be defined. An Ada unit can be taken under control in a history. If you want to edit it, you first have to check it out — it gets a new version number. After the changes, you can check it in again, i.e. make the changes permanent (or you abandon your changes, i.e. go back to the previous version). You normally check out units in the development view only; check-outs in release views can be forbidden.
You can select which version shall be the active one; normally it is the one latest checked in. You can even switch histories to get different development paths. e.g. different bodies of the same specification for different targets.
ObjectAda is a set of tools for editing, compiling, navigating and debugging programs written in Ada. There are various editions of ObjectAda. With some editions you compile programs for the same platform and operating systems on which you run the tools. These are called native. With others, you can produce programs for different operating systems and platforms. One possible platform is the Java virtual machine.
These remarks apply to the native Microsoft Windows edition. You can run the translation tools either from the IDE or from the command line.
Whether you prefer to work from the IDE, or from the command line, a little bookkeeping is required. This is done by creating a project. Each project consists of a number of source files, and a number of settings like search paths for additional Ada libraries and other dependences. Each project also has at least one target. Typically, there is a debug target, and a release target. The names of the targets indicate their purpose. At one time you compile for debugging, typically during development, at other times you compile with different settings, for example when the program is ready for release. Some (all commercial?) editions of ObjectAda permit a Java (VM) target.
DEC Ada for VMSEdit
DEC Ada is an Ada 83 compiler for VMS. While “DEC Ada” is probably the name most users know, the compiler is now called “HP Ada”. It had previously been known also by names of "VAX Ada" and "Compaq Ada".
DEC Ada uses a true library management system — so the first thing you need to do is create and activate a library:
ACS Library Create [MyLibrary] ACS Set Library [MyLibrary]
When creating a library you already set some constraints like support for Long_Float or the available memory size. So carefully read
HELP ACS Library Create *
Then next step is to load your Ada sources into the library:
ACS Load [Source]*.ada
The sources don't need to be perfect at this stage but syntactically correct enough for the compiler to determine the packages declared and analyze the
with statements. Dec Ada allows you to have more than one package in one source file and you have any filename convention you like. The purpose of
ACS Load is the creation of the dependency tree between the source files.
Next you compile them:
ACS Compile *
Note that compile take the package name and not the filename. The wildcard * means all packages loaded. The compiler automatically determines the right order for the compilation so a make tool is not strictly needed.
Last but not least you link your file into an
ACS Link /Executable=[Executables]Main.exe Main
On large systems you might want to break sources down into several libraries — in which case you also need
ACS Merge /Keep *
to merge the content of the current library with the library higher up the hierarchy. The larger libraries should then be created with:
ACS Library Create /Large
This uses a different directory layout more suitable for large libraries.
DEC Ada IDEEdit
Compiling our Demo SourceEdit
Once you have downloaded our example programs you might wonder how to compile them.
First you need to extract the sources. Use your favorite zip tool to achieve that. On extraction a directory with the same name as the filename is created. Beware: WinZip might also create a directory equaling the filename so Windows users need to be careful using the right option otherwise they end up with wikibook-ada-1_2_0.src\wikibook-ada-1_2_0.
Once you extracted the files you will find all sources in wikibook-ada-1_2_0/Source. You could compile them right there. For your convenience we also provide ready made project files for the following IDEs (If you find a directory for an IDEs not named it might be in the making and not actually work).
You will find multi-target GNAT Project files and a multi-make Makefile file in wikibook-ada-2_0_0/GNAT. For i686 Linux and Windows you can compile any demo using:
gnat make -P project_file
You can also open them inside the GPS with
gps -P project_file
For other target platform it is a bit more difficult since you need to tell the project files which target you want to create. The following options can be used:
- style ("Debug", "Release")
- you can define if you like a debug or release version so you can compare how the options affect size and speed.
- os ("Linux", "OS2", "Windows_NT", "VMS")
- choose your operating system. Since there is no Ada 2005 available for OS/2 don't expect all examples to compile.
- target ("i686", "x86_64", "AXP")
- choose your CPU — "i686" is any form of 32bit Intel or AMD CPU, "x86_64" is an 64 bit Intel or AMD CPU and if you have an "AXP" then you know it.
Remember to type all options as they are shown. To compile a debug version on x86-64 Linux you type:
gnat make -P project_file -Xstyle=Debug -Xos=Linux -Xtarget=x86_64
As said in the beginning there is also a makefile available that will automatically determine the target used. So if you have a GNU make you can save yourself a lot of typing by using:
or even use
to make all examples in debug and release in one go.
Each compile is stored inside its own directory which is created in the form of wikibook-ada-2_0_0/GNAT/OS-Target-Style. Empty directories are provided inside the archive.
APEX uses the subsystem and view directory structure, so you will have to create those first and copy the source files into the view. After creating a view using the architecture model of your choice, use the menu option "Compile -> Maintenance -> Import Text Files". In the Import Text Files dialog, add "wikibook-ada-2_0_0/Source/*.ad?" to select the Ada source files from the directory you originally extracted to. Apex uses the file extensions .1.ada for specs and .2.ada for bodies — don't worry, the import text files command will change these automatically.
To link an example, select its main subprogram in the directory viewer and click the link button in the toolbar, or "Compile -> Link" from the menu. Double-click the executable to run it. You can use the shift-key modifier to bypass the link or run dialog.
The following describes using the ObjectAda tools for Windows in a console window.
Before you can use the ObjectAda tools from the command line, make sure the PATH environment variable lists the directory containing the ObjectAda tools. Something like
A minimal ObjectAda project can have just one source file. like the Hello World program provided in
To build an executable from this source file, follow these steps (assuming the current directory is a fresh one and contains the above mentioned source file):
- Register your source files:
X:\some\directory> adareg hello_world_1.adb
This makes your sources known to the ObjectAda tools. Have a look at the file UNIT.MAP created by adareg in the current directory if you like seeing what is happening under the hood.
- Compile the source file:
X:\some\directory> adacomp hello_world_1.adb Front end of hello_world_1.adb succeeded with no errors.
- Build the executable program:
X:\some\directory> adabuild hello_world_1 ObjectAda Professional Edition Version 7.2.2: adabuild Copyright (c) 1997-2002 Aonix. All rights reserved. Linking... Link of hello completed successfully
Notice that you specify the name of the main unit as argument to adabuild, not the name of the source file. In this case, it is Hello_World_1 as in
More information about the tools can be found in the user guide Using the command line interface, installed with the ObjectAda tools.