Replacing the frotz build system

The custom makefile build system in frotz is rather unfortunate. I wanted to add a better sound backend to frotz, but the current build system really gets in the way of working on the code.

I’d like to replace the custom makefiles with a CMake implementation. Before doing the work however, I’d like to ask whether this is actually wanted.

I looked at using CMake for Frotz and came away with the conclusion that it’s too complicated for what it would do for Frotz and would cause problems for building on old systems. What sort of sound backend are you thinking of? My project to hire Mark McCurry was derailed by a death in the family. I’m working right now to get that back on track.

I’ve only just started using CMake, but I’d say go ahead. It’s not like it prohibits the classic Makefile from being used by those who’d prefer it.

I was looking at the different sound systems currently in frotz, and it has three of them. Two for curses (libao and plain OSS) and one for sfrotz (based on SDL_mixer.) I was thinking about replacing all three with just one that is used for both frotz and sfrotz, and uses SDL (in audio-only mode in the case of curses frotz and possibly dfrotz.) This would also get rid of SDL_mixer, which is rather limited and can’t play multiple audio streams at the same time. OSS support would be handled automatically by SDL.

I wrote some audio code for my own projects, which I extracted into a small library a couple years ago and I would just import that into frotz. It’s a rather thin layer on top of the underlying decoding libraries (like libvorbisfile) and automates mixing and resampling. It can play audio streams directly from within other files (no need to extract “chunks” from blorb files and such) using SDL’s RWops. Basically you just point it to something and call play():

(A “hello world” example is at the bottom of that page.)

However, it’s a C++14 library, and since you mentioned you intend to support very old systems, I now am not sure if this is actually something that can be added to frotz.

If you think it can be added nonetheless (as a replacement for sfrotz’s audio system only, and as an option for curses frotz and dfrotz) it’s certainly possible to keep using a handwritten Makefile. It’s just that it’s difficult to work with. Not that CMake is a prime example of good design, mind you :stuck_out_tongue: It’s more like something people have to use rather that something they want to use.

That would mean two separate build systems have to be maintained. That’s not something I would recommend.

I removed the OSS code because it rapidly became unworkable when I tried to extend it to MOD and OGG playback. I did implement audio output for the curses interface using SDL, but I decided not to merge it to the main branch because of all the subdependencies it requires. Again, this goes with my mission of making sure Frotz works on old hardware. Libao is much nicer in that regard and will interface with whatever lower-level audio subsystem is available.

One of the old platforms I’m particularly fond of is 32-bit Sparc workstations running SunOS. I’m not clear how or if SDL can be run there, but libao can. I’ll see what the cctalk mailing list has to say.

That’s why I’m not keen to implement CMake for Frotz.

It’s unlikely that this platform has a compiler available that can compile modern C++ code anyway.