Create Classic Mac APPs with macMAKE!

[ptricky]

Hey everyone, wanted to share my latest project that looks to help bridge the gap when it comes to building apps for classic Macs, specifically PPC and 68K apps for OS 7~9. I used LLms, mostly Codex, extensively for this work.

The idea was to bring the ability of CodeWarrior to the command line. Retro68 is a fantastic tool, but I found it difficult to build anything beyond basic applications. I asked "what specifically does CodeWarrior do when it is building an app? What made it work the way that it did and how did it handle all the elements it takes to create an application for Mac OS?"

v0.1 release path builds Classic Mac OS 9 PowerPC CFM/PEF applications, validates their structure, and packages their files in MacBinary II. Earlier PowerPC versions of System 7 and Mac OS 8 are not currently supported in this version but I have been able to begin building applications for older systems in the current dev build and will release the updates soon.

The ability to utilize languages that never existed on the classic systems is also already proven. For example, I was able to use macMAKE to create an application primarily in Rust. macMAKE itself is built with Rust so it made sense to give it a shot and I have previously done some experiments with using Rust with CodeWarrior itself. This not only means the limits of CodeWarrior projects, such as large amounts of files, is no longer an issue. I have made my way almost all the way through building Classilla with its original project files. I have learned so much from Classilla and I'm forever grateful for the work Cameron put into that legendary browser.

Either way, if you are a traditional programmer or even a slop jockey such as myself, this opens the door for almost anyone to start building apps for classic Macs.

macMAKE — Build Classic PowerPC software from Linux

Build Classic PowerPC Macintosh software from Linux with macMAKE, a C-focused CFM/PEF toolchain with bounded experimental M68000 support in v0.1.1.

macmake.dev

 

[nilobject]

Great idea, and v0.1 is impressive. I built a Mac OS 9 PPC window and menu app in 0.2 s on Linux, and every PEF, MacBinary and Finder check passed. Some notes from a first try:

1. Installer: install.sh failed for me because the macMAKELibs layout didn't match what the script expected. I had to install the archive by hand and sparse-checkout the libraries. A CI test that installs from a clean machine would catch this.
2. SDK setup: finding MSL and Universal Interfaces is the hardest part. A macmake sdk fetch --minimal that pulls only what a C PPC target needs would make first builds much easier.
3. 68k: a lot of the classic Mac scene still targets 68k and System 6/7, which is where Retro68 wins today. A roadmap for 68k, even CFM-68k, would help people decide whether to switch.
4. Rust and C++: you mention Rust works. Ship a Rust sample and say what C++ supports, because the site reads as C-only.
5. CodeWarrior import: building Classilla from its own project files is a huge proof point. Write it up with the steps, and mark which CW XML features are supported.
6. Testing on a real OS: builds pass the structural checks, but an optional macmake run that boots a QEMU or SheepShaver image and launches the app would close the loop.
7. Analytics: good that it's opt-out and stated up front. Make --no-analytics work on the curl pipe too.

I'll keep Retro68 for 68k for now, but I'll use macMAKE alongside it for PPC. Looking forward to the System 7/8 builds.

 

[ptricky]

Thank you for the feedback! Going from an internal tool to a public binary for a CLI tool is definitely new to me and that helps a lot.

 

[ptricky]

Great idea, and v0.1 is impressive. I built a Mac OS 9 PPC window and menu app in 0.2 s on Linux, and every PEF, MacBinary and Finder check passed. Some notes from a first try:

1. Installer: install.sh failed for me because the macMAKELibs layout didn't match what the script expected. I had to install the archive by hand and sparse-checkout the libraries. A CI test that installs from a clean machine would catch this.
2. SDK setup: finding MSL and Universal Interfaces is the hardest part. A macmake sdk fetch --minimal that pulls only what a C PPC target needs would make first builds much easier.
3. 68k: a lot of the classic Mac scene still targets 68k and System 6/7, which is where Retro68 wins today. A roadmap for 68k, even CFM-68k, would help people decide whether to switch.
4. Rust and C++: you mention Rust works. Ship a Rust sample and say what C++ supports, because the site reads as C-only.
5. CodeWarrior import: building Classilla from its own project files is a huge proof point. Write it up with the steps, and mark which CW XML features are supported.
6. Testing on a real OS: builds pass the structural checks, but an optional macmake run that boots a QEMU or SheepShaver image and launches the app would close the loop.
7. Analytics: good that it's opt-out and stated up front. Make --no-analytics work on the curl pipe too.

I'll keep Retro68 for 68k for now, but I'll use macMAKE alongside it for PPC. Looking forward to the System 7/8 builds.

macMAKE v0.1.1 has now been released, and your feedback directly influenced what went into this update. I've addressed all seven points, although some are naturally still in their early stages.

Installer: You were absolutely right about the macMAKELibs directory mismatch. That's been fixed, and I've added clean-environment installation tests that go beyond simply verifying the installer. They install macMAKE, configure the SDK, build a PowerPC application, and validate the resulting artifacts.

SDK setup: implemented macmake sdk fetch --minimal. It uses a pinned revision and sparse checkout to retrieve the required files rather than making users assemble the entire historical SDK manually. There are still some requirements around the historical MSL libraries, but the initial setup process is considerably simpler.

68K: This has progressed beyond just a roadmap! v0.1.1 includes an experimental native Motorola 68000 compiler and application-building path, producing traditional Macintosh CODE resources without relying on Retro68. It's still limited to a relatively simple application model, and I wouldn't suggest replacing Retro68 for established 68K projects yet. Broader System 6/7 support and CFM-68K remain future goals. I've also published a roadmap and compatibility information.

Rust and C++: There's now a genuine Rust interoperability example. Rust compiles into a PowerPC XCOFF object using an external compiler, and macMAKE links it into a Classic Macintosh application. It's a proof of concept rather than full Rust language integration. I clarified the present C++ limitations in the documentation instead of suggesting complete support.

CodeWarrior import: Expanded the documentation for macmake import-cw-xml, including supported features, limitations, and the Classilla development work. Classilla is still a work in progress, and I'm careful not to claim I've completed a clean full application rebuild.

Real OS testing: macmake run is now available! It supports an interactive QEMU workflow using a user-provided Mac OS 9.2.2 installation. I also completed an actual runtime acceptance test: macMAKE built makePAD, which launched in Mac OS 9.2.2, accepted text, displayed its unsaved-changes dialog, and exited normally. The runner captured verified screenshots, and the original disk image remained unchanged. Application launching inside Finder is still manual, but this closes much of the gap between structural verification and actual runtime testing.

Analytics: The piped installer now properly accepts --no-analytics:

curl -fsSL https://macmake.dev/install.sh | bash -s -- --no-analytics

Tested the opt-out and confirmed that it persists.

The biggest goal with v0.1.1 was to improve the experience of actually using macMAKE, rather than just adding compiler features. I am working toward a longer-term goal of replacing the historical SDK and runtime-library dependencies with our own implementations, so developers won't have to hunt down old CodeWarrior components.

You can find the new release here:

Release macMAKE v0.1.1 — Linux Release · mplsllc/macMAKE

macMAKE v0.1.1 — Linux Release macMAKE is a Linux-native development toolchain for creating Classic Macintosh applications. macMAKE v0.1.1 delivers seven release enhancements, verified Mac OS 9.2.2...

github.com

Website and documentation:

macMAKE — Build Classic PowerPC software from Linux

Build Classic PowerPC Macintosh software from Linux with macMAKE, a C-focused CFM/PEF toolchain with bounded experimental M68000 support in v0.1.1.

macmake.dev

I completely understand sticking with Retro68 for 68K work for now. It's a mature toolchain, and macMAKE still has a lot of ground to cover in that area.

Thanks again for the feedback. It was genuinely useful, and I wanted you to know that your suggestions are the kind of thing that helps me understand what other developers need to work with macMAKE.

 

[nilobject]

Thanks for turning those around so fast. I tried v0.1.1 from a clean Linux machine:

1. Installer: the piped install with --no-analytics worked first time in 12 s, and the opt-out stuck. strace showed no network calls during a build.
2. sdk fetch --minimal: 14 s and 18 MB, then doctor said READY, and the C sample built in 0.17 s with every inspect check passing. Big improvement.
3. 68k: hello-window-68k built in 0.05 s with a valid jump table and CODE 1. Impressive for a from-scratch compiler.
4. The Rust sample and the import-cw-xml docs are clear and honest about their limits. The Supported/Partial/Unsupported table is exactly right.

Some suggestions for the next round:

• macmake run: copy the built app onto an HFS image attached as a second drive, so nobody has to move files into the guest by hand.
• System 7/8: the PPC sample needs CarbonLib. A non-Carbon sample with a runtime result on 7.5/7.6 and 8.x (SheepShaver) would back up the "7~9" claim.
• 68k: a boot result on System 7 (and 6.0.8 if you can) in Mini vMac or Basilisk II, a smaller default SIZE for low-memory Macs, then multi-segment support.
• Retro68: a documented way to link Retro68 objects, or compare outputs, would let people adopt it gradually.
• Small fixes: macmake update check times out at 1 s (GitHub took about 2 s here), and the compatibility table is still labelled v0.1.0.

works on both systems in Snow: System 7.5.5 on a Mac IIx and System 6.0.8 on a Mac Plus, docs need updating. The Plus needed 4 MB, because our 6.0.8 disk crashes at 1 MB even before the app starts.

system 6.0.8

system 7.5.5

 

[ptricky]

Thanks again for testing and giving detailed feedback! I'm currently working on completely replacing the CodeWarrior lib dependencies and other third party sdk files do macmake owns all components and it can be clear. I'll add your thoughts to the top of the to-do tough, thanks again.