Changes between Version 5 and Version 6 of kBuild


Ignore:
Timestamp:
May 26, 2007, 10:57:08 PM (18 years ago)
Author:
bird
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • kBuild

    v5 v6  
    2828It 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...
    2929
    30 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.
     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.
    3131
    3232Another 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.