|
|
tools useful for A-A-P
The intention for A-A-P is to use existing tools as much as possible. To find
out which tools can be used this overview has been compiled.
Some tools cannot be used directly, but function as an example or can be
invoked by A-A-P (e.g., commercial tools and programs which are not portable).
Unless noted otherwise, tools are open-source.
If you find a tool that would be useful for A-A-P but is not listed here, or
when information is incorrect, send a message to
Bram AT a-a-p.org.
Note: this list is not intended to be complete. Information that is
irrelevant for A-A-P is omitted.
Script languages
Build
Install
Issue Tracking
Version control
Browse
IDEs
Various
Script languages
A script language is needed in various parts of A-A-P:
-
The most important use is in the recipes. Here the script language allows
a recipe writer to execute various tasks, without depending on OS-specific
tools. Once the language has been chosen it is very important that it
doesn't change, it would make already written recipes invalid.
-
The A-A-P framework must run on many different Operating Systems.
Implementing it in a script language that runs on many OSes avoids having
to write system-dependent code. This also makes it easy to support adding
plugins.
-
The automatic configuration for a specific system must be OS-independent.
This requires an OS-independent script language.
Using the same script language throughout A-A-P is preferred. This avoids
that a developer needs to learn several languages.
The most important demands for the script language:
- Portable over many different Operating Systems
- Stable; avoid the risk that a future version is not backwards compatible
- Easy to use and understand
- Includes Internet access functionality
- Provides GUI functionality
- Can be debugged
Overview (best candidate first):
- Python
-
Appears to fulfill all demands. It's open-source, is available for all
important Operating Systems, supports internet connections, widely used,
and so on.
Drawbacks are the way indents may cause trouble and speed (compared to
using compiled C).
- Tcl/Tk
-
Appears to fulfill all demands. Tk is the same GUI toolkit that's used for
Python, but it was originally made for Tcl.
A graphical debugger is available. It was designed to be embedded in
appliations. Easy to use networking facilities. Easy to learn.
Compared to Python, TCL is weak on data structures (stores all data as
strings) and less suited for large programs. TCL might require writing
specific things in C or C++.
- Ruby
-
Includes many of the "good things" from Perl. Very modern, uses all the
good things from older languages (e.g., smalltalk).
Full O-O support (better than Python). Very flexible: can add a method to
a class at runtime.
Supports the Tk GUI toolkit.
Disadvantages: O-O features appear to be more important than practical
use. It's not very wide spread yet (compared to Python).
Unknown: How is support for internet access?
- Perl
-
A very powerful language, but Perl files tend to be rather cryptic: "Perl
is a write-only language". The syntax is complex: "Only Perl is able to
parse Perl scripts". That is a bit exaggerated though, it's possible to
write nice Perl scripts with a bit of effort.
There are several ways to use a GUI with Perl, including Perl/Tk, wxWindows
and Qt.
- Scheme
-
Comes from the LISP world. Not everybody likes the syntax. Several
incompatible versions exist.
- Javascript
-
Limited use outside of HTML.
- Java
-
Cannot be executed directly, requires a compiler. Would be difficult to
use in a recipe.
- C#
-
Cannot be executed directly, requires a compiler. Would be difficult to
use in a recipe. Still very new and not widely supported.
- Shell script
-
Not portable, because a shell script depends on external programs.
There are many script languages that are not mentioned here, because they are
not widely used.
|
|
