I've always been very interested in the build process and build tools. At every place I've worked, improving the build process has been a side project of mine. Yet, I was never satisfied. Existng tools were either too 'low level' in their conception or to narrow in what they handled. What I wanted was something as elegant as an IDE's "Build Project" button, but flexible enough to handle my Ruby scripts, database setup, bash scripts, and external documentation along with my Java code.

After working on the general problem for awhile, I realized that part of the problem was that the generalized tools, like Ant and make had no idea of a package. Build units were opaque files or actions. What I wanted was to define a "project" and have the build system intuit what would be necessary to build, test, document, and deploy.

The build systems didn't look at the project like developers did. They were simply specialized scripting langeagess and perscriptive, rather than descriptive, in nature.

YMake works entirely from a descriptive paradigm. Users describe their projects (these are the source files, these are the test files, it provides these libraries, etc.) and YMake understands from this description how to build, test, document, deploy, package, analyze, and install a project. The first thing to notice about this approach is that users now only need to maintain as many descriptions as there are projects rather than maintnaining multiple scripts for each project action tuple.

There are of course systems and tools that take a descriptive/project oriented approach, but in my experience, they all have one crippling limitation: they are too narrow in what they handle. My IDE, for instance handles Java files and even vanilla Java web applications and J2EE, but has no idea what to do with the Ruby scripts, SQL schemas, bash scripts, or extra-code documentation that make up my projects. In fact, there are lots of tools that cover many different mixes of technologies, but I wanted to be free to use whatever I wanted whenever I wanted, which is why before YMake, I preferred plain old make to the more specialized build systems.

The other serious limitation of the specialized build systems was their support for actions. I wanted to be able to build, test, document, deploy, and package from the same tool for all my projects. This means being able to use the same tool to deploy and configure Postgres and MySQL, configuring Apache to handle PHP and JSP, and being able to handle whatever database or webserver I want to use next year.

Ultimately YMake seeks (and largley succeeds) to handle all development tasks except the actual writing of source code (or documentation, etc.), and to do so in an intuitive fashion. And enabling this functionality is relatively easy, often requiring only four or five lines. As a quick comparison, I compared my own YMake enabled code, comprising about 40 projects, which has 377 lines (including comments and blanks) of YMake definitions against an earlier (smaller) snapshot of the code base which had over 3,000 lines of Makefile code. Not only is the YMake code much smaller, but it delivers far more comprehensive and fine grained functionality.

While the functionality of YMake is nothing new, the key that it delivers the funtionality intuitively and with very little work. With YMake a single developer can drop daily tests, packages, code reports, and documentation with very little effort.