The Aap program executes recipes.
It is a kind of super-make program.
In a recipe you describe how to perform a certain task.
Like a Makefile it contains dependencies and build commands.
Additionally, many powerful features are included, so that you can use a
recipe to:
- Build a program by just specifying the program name and the
source files
- Maintain a web site (the A-A-P site is generated and uploaded
with a recipe)
- Download the latest version of files
- Distribute files to several servers at once
- Obtain a module from CVS
- Commit changes to CVS; add and remove files automatically
- Generate and filter files
- Build several variants and on multiple platforms with little
effort
|
Advantages
Using a recipe works better than a Makefile in many ways:
- Uses signatures to avoid trouble with timestamps
- Integrated support for up- and downloading
- Avoids shell commands for greater portability
- Includes the power of Python script
- Automatically figures out dependencies on included files
- Avoids line continuation mistakes
- Good support for a project with multiple directories
|
Status
A-A-P version 1.0 has been released.
All essential features are working.
Testing has been done on Unix, MS-Windows and Mac OS X.
The automatic mechanisms only work for C.
You can add support for other languages.
Hopefully more tools and languages will soon be supported, this depends on
volunteers to help developing A-A-P.
Not everything has been properly tested. Use with care!
|
|
The A-A-P GUI IDE is a framework in which separate tools can work together.
Like any other Integrated Development Environment it supports:
- Creating a project
- Building and executing a program
- Browsing files
- Debugging a program while displaying source code
|
Read the tutorial to get an idea of what you can
use Agide for. Click on this image to see a screendump of Agide being used for
debugging:
Framework
Agide is not a monolitic application.
Separate tools can be plugged in.
Thus you are not forced to use one editor.
Each tool implements part of the plugin interface.
This interface makes it possible for a tool to communicate with other tools,
without the need to know how the other tools work.
For example, an editor can set a breakpoint in a file, without knowing what
kind of debugger is being used.
And the debugger can show the PC position in a source file, without knowing
what editor is being used.
Status
Currently only a few things are supported:
- Using an A-A-P recipe for a project
- Debugging with gdb
- Editing with Vim
- Unix
|
Hopefully volunteers will help adding their favorite tool.
Since it is relatively easy to add a tool, this list is expected to grow
quickly.
Not everything has been properly tested, use with care!
|
