The build system used by the Wavepacket family of source repositories (wavepacket-lib, wave-glut, wave-audio, aesop, folium). More...
|
Modules | |
| Build System Makefiles | |
The Makefile is very basic: it is standard GNU makefile format. | |
| Build System Config files | |
The second file is the config file. | |
Detailed Description
The build system used by the Wavepacket family of source repositories (wavepacket-lib, wave-glut, wave-audio, aesop, folium).
This home-grown build system came out of early attempts to get recursive and dependent builds working, plus my initial stabs at Perl programming.
Eventually, this system should be replaced by an open source standard build system. But this is used for now.
Features of the wavepacket build system:
- Separate directories for source and object files. So when you build, your source directory stays clean. Object files (and other build artifacts) are put in dedicated directories in a parallel tree.
- Support for dependent modules. So if you build an application that depends on multiple libraries, those will be built and linked in the correct dependency order. Also, the dependencies are recursive. So if you create an application that declares a dependency on library A, and library A declares a dependency on library B, when you build your application the build system will also build and link both libraries.
- Support for cross-repository builds. This is necessary because I have multiple projects, each with their own SVN repository, that depend on each other.
- Support for GNU autoconf packages. That is, you can use the build system to create distributable tar'd packages that support autoconf and automake. This is obviously handy to create versioned public releases.
GNU Autoconf support is primitive for now, but I will update it over time.
To use the build system, any buildable object (application or library) must supply two files: a config file (named "config") and a Makefile (named "Makefile"). I thought of the names myself.
A buildable object must be in its own directory. A given directory can only contain a single object (library or application).
The build system does make one assumption: all of your repositories are listed as peers in the same parent directory. For instance, I've got an svn directory that contains both wavepacket-lib and folio as child directories. As a developer, it is up to you to acquire local versions of necessary repositories.
The build system will create an "obj" directory within each repository, and all object files and other build output for modules in that repository will be contained in that obj directory. The obj/bin directory contains "installed" versions of applications (applications and tools will automatically copy their built executable to obj/bin), so it is a clean directory to use for executing built binaries.
It is also possible to build resources into a binary as part of the build system. See common_resources .
