Hello, World (Platinum Enterprise Edition)
I hope you agree that this build system sounds awesome. But is it for real? To demonstrate and explore its capabilities, I will follow an imaginary software team that just started working on a new project.
The project is called "Hello, World!". The goal is to print it to the screen. To do this, over the course of this series the team will create a complex project with multiple executables, static and dynamic libraries, and even Ruby bindings. The project will run on Windows, Linux, and Mac OS X. It will be built using a custom build system. To whet your appetite, here is a prototype in Python of the finished project:
print 'Hello, World!'
Isaac, the sage development manager, assembled a team of brilliant software developers with umpteenth-years of experience in delivering high-performance enterprise applications. The kick-off meeting went well and the developers quickly reached a few decisions:
- The project will be developed mostly in C++,
- The system must be cross-platform and support Windows, Linux, and Mac OS X,
- The developers will be divided into four teams.
- Team H will develop a static library called libHello that returns "Hello".
- Team P will develop a dynamic library called libPunctuator that produces commas and exclamation points (and can be reused in future projects requiring punctuation).
- Team W will develop the complicated libWorld static library that must return the long and difficult word "World".
- Team U will develop an infrastructure project called libUtils that provides utility services to the other teams.
- The project will also deliver a Ruby language binding to make it more buzzword-compliant.
- The test strategy is to develop multiple test programs to test every library. Each team will be responsible for developing the test program for its library.
- The build system will be developed in Python by the renowned build expert Bob (aka "The Builder"). (No connection to Microsoft Bob, thank you.)
Bob carefully observed the source and required artifacts of the system and came up with the following directory structure. Each kind subproject is contained in a top-level directory under the source tree:
root |___ ibs |___ src |___apps |___bindings |___dlls |___hw (static libraries) |___test
- The ibs directory contains the files and templates of the build system. Note that it is completely separate from the source tree under src.
- The src directory contains all the source files of the system. Let's take a quick look at the top-level directories under src.
- apps. This directory contains all the (executable) applications generated by the system. Each application will have its own directory under apps.
- bindings. This directory will contain Ruby bindings at some point. At the moment it is empty.
- dlls. This directory contains the project's dynamic libraries.
- hw. This directory contains the project's static libraries. The reason it is called hw (as in "hello world") and not libs or a similar name is that it is very important to prevent name clashes with system or third-party static libraries. The automatic dependency discovery of the build system relies on analysis of #include statement. The unique hw part of the path of each static library allows unambiguous resolution of #include statements.
- test. This directory contains a subdirectory for each test program. Each test program is a standalone executable linked against the static libraries it is designed to test.
In the next installment of this series, Bob and I delve into the innards of the build system and explain exactly how it works. Stay tuned.