The ccbuild goal is to allow the developer to run only one command: ccbuild. ccbuild program will then find out what it should do on it's own, and start updating any source connected to your current programs (by looking at #include statements).

Currently the program can do this using only the information from your source code and a file containing information about compilation parameters that are needed when a specific global include ("#include ") is used.

The main difference with other build tools is that, during the development phase, ccbuild should be able to find it's own way: no part of the build should have to be scripted! This is also why ccbuild is very system specific and only runs on Linux (and hopfully any other platform that looks like it).

When developing C++ programs according to a standard of "a file per function, a directory per class" your filesystem will be in constant turmoil. When you use the GNU autotools you will have to edit your Makefile.am for every function and sometimes let the tools re-evaluate your whole system!

This, of course, will not do. So, I set out to create a tool to aid me in my development phase. Mind you, the autotools are great for portability and distribution, but during development they kept me from good coding ethics.

Here are some key features of "ccbuild":

· Fully automated building, with only one simple command.· Automatic dependency resolution by reading the sourcecode.· Automatic binary target resolution.· Semi-automatic library and linking resolution (via a simple configuration file).· Specific object file cleaning.· Separation of object files an source by using an "o" directory for output.· Monolithic makefile generation (without a clean rule at the moment).· Header include graphs using the Graphviz DOT language (example).· Support for ".cc" and ".cpp" extensions.

When run without any options ccbuild will issue the command "build". For every .cc file in the local directory: if it contains an "int main" function, it will be seen as a binary target. For every binary target, ccbuild will follow it's includes to other directories and see all .cc files in those directories as objects (if they don't have an "int main" function). It will then compile the object, keeping any linker options back for the binary target. To know what linker options to use, see Resolution.

To be able to link the binary, the compiler needs to know what libraries to link to and of course what include paths need to be added. The ccbuild utility assumes that for every extra comipler argument, there is a global include that can indicate it's needed.

When a global include is encountered ("#include ") it will try to resolve it by looking it up in it's table, issueing a warning if it is not found in the resolution table or in "/usr/include" or in "/usr/include/g++-3/". The table of resolutions is loaded from tab saperated configuration files "ccResolutions" and "~/.ccbuild/ccResolutions" (in that order).

Currently this can only support options for either link OR compile time. (See TODO: "Propper...") Which means you cannot mix "-I" (include) and "-l" (library) options yet.

An example configuration file wich currently is useful is (notice the tab between "png.h" and "-lstdc++ -lpng -lz"):

png.h -lstdc++ -lpng -lzsqlite3.h -lsqlite3

Limitations:

· Any source file that needs to be compiled into an executable must contain a main function returning an int.· All code needed for a class must be contained in one directory (all .cc files are taken to be object targets for the main program including the header in the same directory).· Currently source files need to have one of these extensions: '.cc', '.cpp', '.h', '.hh', '.ih', '.tcc'. Any other extension is not seen or interpreted in the wrong way.

Requirements:

Known compile-time dependencies:

· flex 2.5.31

Known run-time dependencies:

· g++

What's New in This Release:

· Move to libgcrypt for the MD5 implementation to allow ccbuild to be packaged· Remove automate.cache from distribution source package· Bashisms removed from tools/*.sh