Changes between Version 4 and Version 5 of kBuild


Ignore:
Timestamp:
Dec 13, 2006, 4:08:56 AM (18 years ago)
Author:
bird
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • kBuild

    v4 v5  
    22
    33kBuild is a makefile framework for writing simple makefiles for complex tasks.
    4 
    5 === History ===
    6 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.
    7 
    8 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.
    9 
    10 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...
    11 
    12 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.
    13 
    14 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.
    15 
    16 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).
    174
    185=== The (current) kBuild Design ===
    … …  
    3219=== What kBuild Does Not Do ===
    3320[wiki:kBuild 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.
     21
     22
     23=== History ===
     24The 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.
     25
     26IBM 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.
     27
     28It 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...
     29
     30My '''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.
     31
     32Another 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.
     33
     34When 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).
     35