About kBuild …

kBuild is a makefile framework for writing simple makefiles for complex tasks.

The (current) kBuild Design

The goals of the kBuild framework:

1. Similar behavior cross all supported platforms.
2. Flexibility, don't create unnecessary restrictions preventing ad-hoc solutions.
3. Makefile can very simple to write and maintain.

There are four concepts being tried out in the current kBuild incaration:

1. One configuration file for a subtree automatically included.
2. Target configuration templates as the primary mechanism for makefile simplification.
3. Tools and SDKs for helping out the templates with flexibility.
4. Non-recursive makefile method by using sub-makefiles.

What kBuild Does Not Do

kBuild does not provide any facilities for checking compiler/library/header configurations, that's not in its scope. If this is important for your project, check out the autoconf tool in the GNU build system. It is possible to use kBuild together with autoconf if you like, but you might just as well use the full GNU package.

History

The framework is based on previous experience with the Microsoft / IBM NMAKE tool. A lesson learned there was that the framework should not restrict the user unless its vitally necessary (that framework ended up being very rigid and inflexible). NMAKE wasn't a great tool to work with since it lacked everything that was needed to do fancy stuff - and the versions that did have any good stuff wasn't stable and there wasn't any chance of getting it fixed. Lesson learned here, source code for *everything* the framework depends on is paramount.

IBM once created a cross platform build framework called ODE, which I think is still available for download somewhere though I don't think it's really maintained any longer. I had to with some code which used this once and found it interesting but kind of slow. Since it apparently was based on a modified BSD make, but since it being BSD no source was available. It also included a custom driver program for make which would setup the environment based on some project configuration files and environment variables. There was a bunch of nice concepts here, like tool independent parameters, the tool setup, the pass configuration, and lot of things I've forgotten.

It was after working with ODE that I started looking at the BSD make program and seeing how much work it would be to make it able to do the same things my way... Traces of these experiments can still be found in the kBuild subversion if you go far enough back in the history. One of these "exercises" was kicking the BSD make into behaving like NMAKE, IIRC it was taken to a state where it would be able to run the NMAKE build framework but without doing everything that NMAKE could. But then I got busy with other things and had no real use for it...

My real introduction to GNU make came when working on GCC for OS/2 and the InnoTek LIBC (now kLIBC) where Andrew wrote some really cute makefiles which I ended up having to maintain. This including having to fix them so they would work with the various GNU make 3.81 alphas and betas, and to change them to use new features in 3.81 that allowed me to do the makefile generation in memory rather than on disk. I found the defines and functions concepts intriguing after the feature starved NMAKE world and not being able to kick BSD make into doing everything I wished for.

Another thing I realized (once again) working on kLIBC and GCC was that makefiles usually ends up depending on external tools other than just the compiler, linker and librarian. I've lost count on how many times I've had to help figuring out weird build breaks which was caused by a different shell, an innocent environment variable, different sed or gawk, a broken td, or similar stupid things. And this was just on one single platform with kind of low activity. Now thing going for crossplatform... So, a cross platform framework must try provide similar behavior on all platforms. The simplest way of doing that is naturally to provide all the tool it uses, and do the necessary changes to force them to behave correctly.

When I restarted the work on a make framework back in 2004 the obvious choice was to use GNU make 3.81 for the makefiles. For the other tools I usually prefer the BSD version over the GNU one because the BSD code is usually simpler, has less dependencies and is easier to port (to Windows). That is, if the BSD version exist and provides the necessary features (SED didn't and therefore it's GNU).