KempoMake : Limitations

(Last updated 03/02/03)

Due to the way the build system works, and how some compiler tools work, the following limitations exist (fixes to any of these would be appreciated.):

• Sample code for the library thinks the project name will be “SampleLib” and sample code for the application thingks the project name will be “SampleApp” - This could be fixed with a sed script, if someone would like to write one, I'd be grateful. common-tools.mk is where you'd put in the $(SED) command. (After the $(CP) commands.)

• You cannot use the Create/Add tools from a platform other than the one you are compiling with. Example, you cannot create a x86/Win32/cw directory tree from within a mips/Linux/gcc build environment.

• We have two systems in place currently within KempoMake, one that “makes” source files into binary objects, and potentially(because there's currently no support for this) one that “makes” resource files into binary objects. All should be able to be linked into one final application in the link step, in a cross-platform manner.

• Better support for compiler directories. Currently mips/Linux/gcc is kinda messy and x86/Win32/cw is atrocious.

• Better sample code; although there will potentially be a public release of the KempoAPI in the future to resolve this issue.

• .err files aren't actually error logs. They just contain stdout output currently. I'm not sure how to save errors and yet still show them on screen. make likes to quit at the first sign of trouble and I'm not sure there's much that we can do about it.

• Support for “RUN”ing doesn't currently exist. Ideally you'd run a command line that would build the build level then run the emulator or whatever post linking step. Ideally something like the command line below, however its just not implemented yet:

make -r -R BUILD=FINAL PLATFORM=x/y/z RUN=true

• Java as a target platform should probably use the build levels properly and be able to use the above RUN idea. Hasn't been a high priority since Java doesn't really have different optimizations or debug flags or whatnot. Though I hear this isn't necessarily a constant.

• VCL/VSM doesn't have the best dependancy generation in the world right now. I'm working on it though, and am pretty confident its achieveable.

• VCL doesn't appear to support different directory includes. I'm sure VSM might; but I use VCL myself more, so I suggest that you just keep the includes for VCL files(.m and .i) in the same directory as the .vcl. (Unless you want to do .include ../../../../Headers/a/b/c/ but in my opinion it may not be worth the trouble.

• GCC doesn't like relative references to libraries, so you must provide absolute paths. You should use $(PROJDIR) in your libraries to define the path to what project libraries are needed to be included, project relative-wise. You won't see this problem with Codewarrior on Win32, so be aware.

• You cannot build two “Build Levels” of the same project at the same time. Ie you cannot build DEBUG “foo” while building FINAL “foo” - this is because KempoMake builds one directory level up from the actual target and then moves the file afterwards.

• And because of this, you for sure cannot build two different cpu/Os/compilerbrand versions of the same project at the same time. 99% of the time the object files are going to be named the same(.o) and you're going to end up making something cry trying to link two objects from two different targets together.

• KempoMake will not auto-detect your environment. Part of how KempoMake does what it does is not rely on what one compiler may say the proper directory for a compiler is. Tools(scripts in particular) are provided for each platform to automatically set up a few variables for you.

• VCL spits out a bunch of junk even in quiet mode. There's nothing I can do about this, there's no source to the app so I can't change it.

• Some would say that only three targets, or perhaps, only one target with debug symbols, or perhaps, one target with no assertions is a limit, but trust me, this was definitely intended. It used to be only DEBUG/FINAL at the beginning; you should be thankful you have something in between.