Your Donations help keep my Software going!
I'm on a short vacation and will be back soon.
I'm selling some Homebrew Game Dev Devices. Check it out.
KempoMake : FAQ
What is KempoMake
KempoMake is a system I have used since November 1998. For me it provides exactly what I need to build projects with- a sense of cross-platform capability, ease of use on potential build platforms, and a good way to manage cross-platform libraries and applications. (Keeping compiler flags syncronized and such.)
What is it designed for?
KempoMake addresses three main problems:
- A big problem in prototyping code for cross-platform is keeping code for various platforms in sync with “common code.”
If common code changes, or files are added and deleted to common code, you'll have to update each platform, rather than just the original copy.
KempoMake stores all platforms for any particular project, rather than a project for each platform, so you only have to update one copy ever.
- Synchronizing BUILD options across platforms and libraries/applications is problematic.
Things like leaving debug symbols in final code can happen if you're not careful. What if you miss a big bug on a platform because you've forgotten to turn on the most strict warning level? Or link a final binary with a debug library? Whoops!
KempoMake stores one set of BUILD options per BUILD type per platform, so that everything you build gets built at the proper build level.
- Developing many synchronous libraries at once is near impossible with current IDEs.
What I've found when developing big libraries is that at a certain point, it either makes sense to split development into separate libraries, or to deal with a big library as a set of smaller libraries. This is useful if, for instance, a given small library tends to be rough in development and often doesn't compile. Unfortunately, when a small library doesn't compile, the big one won't either, and this leads to a non-usable big library when you might need it.
KempoMake allows you to create and manage many small libraries individually, so you can keep smaller libraries in active development without heavily impacting a bigger library.
These are the three primary reasons for developing this tool.
What platforms are currently supported?
Two have survived to this date:
- Win32 - Any Windows(32-bit) Visual Studio 2005 SP 1
- Linux - Linux, GCC generic
Planned platforms are console hardware… current, but not limited to ancient.
What is your development environment?
I'm currently on Windows(XP) based PC, however this system could ideally run on any platform supporting GNU and the GCC toolchain.
It has been used previously to prototype applications for PlayStation 2 Linux, Nintendo 64 Homebrew, as well as Palm Pilot.
More questions...
- Q. You assert in the sample code regardless of the BUILD variable?
- Q. You put some platform-specific code in the SampleApp?
- Q. More questions regarding sample code…
- A. I wanted to get a release out fairly quickly, and this at least gives a good starting point for your own projects.
Why are directories and libraries "hardwired?"
Because the -r -R flags with make tell it not to “default” to any particular compiler, rules, or flags. This is intentional, so say we wanted to compile for lots of different devices; gba, ps2, linux, and mac, all at the same time. But say our tools for all of these platforms were hosted on the x86/Linux. If we didn't hardwire, we could accidentally try compiling with the wrong compiler, link with the wrong linker, or something equally insane. Its a small price to pay for portability.
How do I get in touch with you?
Via email: tjgrant [at] tatewake [dot] com
Thanks to who?
The following:
- Marcus R. Brown(http://www.0xd6.org/) for encouraging me to release this.
- Hikey, Sparky, Sauce, etc for SPS2 and the SPS2 tech support Q/A.
- [Your name][Platform support added]
You are here: News » Software » KempoMake » KempoMake : FAQ