abuild - a command line build program

The program manages the build process of applications (like the cmdtools, which are built with this).
It takes the source files, compiles them (if necessary, takes into account the dependecies automatically) and builds the target.
It actually composes command lines and executes them (as if this was done/written by hand).

Main features:

• It works with simple text-based project files.
• Multiplatform applicability: it runs both on Windows and Linux.
• The program is intended for gcc/g++ usage, but other compilers (any command line program) can be used, too (the program itself can be built with C++ Builder, g++ (Linux and Windows) or Visual Studio).
• The project files contain entries with key-value pairs ([key] = [value]). Relatively long lines can be concatenated with '\' at the line end (this is typically the case when several source files are in use).
• Automatic tracking of the source file dependecies (nonstandard headers for C and C++ files). In a normal build only the source files are compiled that have been changed, or any of their corresponding dependecy changed (since the last compilation - that is, the source file modification time is newer than that of the object file).
  The dependencies are stored in .deps files, that describe the the source dependencies (in the same directory with the project file).
• Wildcard file selections for source files (for example if everything is used in a certain directory).
• The directories that are refered to in the settings are don't yet exist, will be automatically created (similarly to the Visual Studio).
• The usage of configurations: different settings can be defined for different (typically debug and release) configurations. The configuration-dependent entries are denoted with an '@config' postix of the entry keys (like target@release). If an entry doesn't contain and @config postfix, it uses the (always existing) default.
  The config names don't have any internal meaning within the program, the proper behaviour always depends on the project file creator (like the 'release' gives only really release versions (without debug information), if the project file contains the appropriate settings for this configuration).
• Pre- and postprocessing of files in the build process.
• Inclusion of other files: when several project uses the same part, it can be extracted to a file and the projects can include this one (they share the same code).
  If something changes in this part, it is enough to modify the included file only.
• Inheritable project settings: the project files can be organized so that a 'child' project file uses certain settings from a 'parent' project. This handles the configurations, too.
• Parallel compilation: the program can use any number processors for the compilation of the sources (the link process cannot be parallelized). This can speed ut the build process singificantly in case of several sources.
• There can be defined variables (with values), in order to avoid the unnecessary value repeats ('macros').
  The variables can be refered to in the $(variable) form (anywhere in the project file, these references will always be replaced with the value of the variable).
  There are aloso some predefined variables, that contain information about the build process (like LINKER, CONFIG, PROJECT - there are no constraints on the variable names, but it is common that they are all uppercase).

The command line parameters:

• -v[erbose]: print the composed and executed commands
• -b[uild]: rebuild everything (the dependencies, the objects files and the target)
• -c[onfig] {configuration}: specify the configuration
• -j {threadcount}: specifiy the number of processors for parallel compilation
• -clean: clean the intermediate files
• -clean-all: clean everything

The available entries in the project files:

• src: sources
• obj: the intermediate directory for the compilation (it is automatically created if it doesn't exist yet)
• includes: the paths of the header files (the -I parameter of the gcc/g++)
• target: the final result of the build process
• defines: symbols for the compilation (the -D parameter of the gcc/g++)
• cflags: the flags of the compilation
• lflags: the flags of the link process (the target to be created)

A simple project file looks like this:

src = main.cpp \  <-- this means that the next line belongs to this entry
      unit1.cpp
target = test

This project first compiles the two cpp files (the main.obj and unit1.obj are created in the 'obj' directory, respectively). Then it links the two object files into 'test'.
The whole process and its results can be seen here:

A more complex project file:

src = main.cpp \
      unit1.cpp \
      unit2.cpp \
      ../common/globals.cpp                           <-- the paths are relative to the project file
includes = ../common \
           ../utils
target = debug/sample
obj@release = obj_release
target@release = release/sample                       <-- when building the release config, the directory will be created, too
cflags = -g                                           <-- debug information for the default config
cflags@release = ""
LINK_FLAGS = -lstdc++                                 <-- common value for the link settings
lflags = $(LINK_FLAGS) -L ../libs/bin                 <-- link to the debug binaries
lflags@release = $(LINK_FLAGS) -L ../libs/bin_release <-- link to the release binaries
postp@release = strip $(TARGET)                       <-- remove the debug information from the target

A real complex example is one of the project file of the cmdtools.