| ||: ||automake builds on top of make and Makefiles, which
themselves have a number of severe limitations. They are not portable,
even between related platforms (as e.g. the most common UN*X platforms).
Furthermore makefiles are limited to one level directories. Managing
complex, multilevel directory projects therefore required repeated
recursive Makefile structures, with Makefile calling itself over and over
again, which is not even not only slow, but also tend to become unnecessary
| ||: ||Makefiles work mostly by internal magics. A large number of
actions are builtin (e.g. how to compile C files), but even more are not.
In Makefiles all the additional logic necessary to work with complex
packages and software is missing, e.g. renaming, moving or deleting files,
zipping and unzipping, filtering and replacing templates, etc. To achieve
this one have to write "bash commands" into the Makefile itself, small
pieces of system shell code, which are defacto seldomly portable.
| ||: ||Moreover limits this "internal magic" the extensibility of
make and makefiles. Not to say that it is impossible, but extending make
for new languages or applications introduces to much logic into the
Makefiles, which should normally be hidden from the normal Makefile
| ||: ||Automake is kind of frontend to the make system; it generates
Makefiles from a simplified Makefile extract. Principal a good idea and
for a lot of projects really usefull, automake lacks the total availability
to be extensible. Automake can't be extended (or even modified) without a
thorough understand of automake's kernel logic.
| ||: ||Portability. Build scripts should work for most
applications and platforms without system specific code and without any
platform modifications. Conditional dependency tracking, dependending on
the local host and os system, should be integrated.
| ||: ||Task based. Very similar to the desprictive nature
of the Ant system (ant)
the real work should be done by "tasks". Tasks are subportions of
functionality, e.g. for compiling C source files, copying files, creating
directories, etc. Tasks are pluggable, and the core distribution should
come with a set of tasks mostly used in normal applications and
| ||: ||Scriptable. Very different to the Ant system
however, Arc is scriptable. Arcfiles can utilize the full power of a
functional programing language with a rich set of functions. This helps in
developing portable script files, even when (normal) tasks are not
| ||: ||API for Tasks. To write a new task (i.e. to extend
Arc), one should only need to understand the API (i.e. the input values,
the return values) and how to encapsulate the action in scheme code.
| ||: ||Absolutely no magic. The Arc kernel does no magic,
i.e. it does not know how do calculate dependencies for
.o-files related to .c-files. It has no builtin
| ||: ||Integrate operating and machine specifics (e.g. which C
compiler to use, which options are accepted). This information should be
added to a database, and a checking tool would set up a (project) local
"Arcconfig" file, which would be used by the arc process. This procedure
would replace autoconfig and the m4 base of tests.
| ||: ||Write tasks!|
| ||: ||Implement a test only mode (just print the command, do work
| ||: ||Better error management|
| ||: ||Pre check; check for cyclical dependencies, check for well formed
| ||: ||Portability. Support to more platforms, especially the critical
and complex plath (task-lib, task-link).