ccbuild 1.5.5

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 its 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 its 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.
Main features:
- 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 its includes to other directories and see all .cc files in those directories as objects (if they dont 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 its needed.
When a global include is encountered ("#include ") it will try to resolve it by looking it up in its 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 -lz
sqlite3.h -lsqlite3
Version restrictions:
- 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.