Fun with Opus, Part 4

If you've been following along with the fun with opus series then you might be thinking at this point that the build process is very streamlined, sure, but also rather clumsy.

The build.ps1 script is straightforward to follow (clone dependencies, extract some specific files as necessary, single command-line compiler invocation, we're done). We need to do additional work to get any sort of code completion assistance, however, as an IDE such as Visual Studio will not be able to follow our new dependencies, even if they sort out the standard library and all that.

Today we're going to clean up the build system, and we might introduce some testing for next time around perhaps, to allow us to keep hacking on this with confidence.

New build process

This is what we want to get to, assuming that you're starting from https://github.com/mlrdevgit/opusfun/tree/main/04 from within an x64 Native Tools Command Prompt for VS 2022 command window.

> mkdir build
> cd build
> cmake ..
> cmake --build .


Setting up CMakeLists.txt file

An Introduction to Modern CMake has most of the techniques you'll want to look at for this sort of refactoring work.

CMake has come a long way and continues to evolve. In part four, we're going to use this CMakeLists.txt file as the basis of our build.

Here are some interesting things

• Supporting an IDE. This is one of the more interesting aspects, and for Visual Studio at least, we don't need to do anything more - the Visual Studio IDE can work with the CMakeLists.txt file as we have it. If we wanted to be fancier, we could use folders to organize our work, but it's not really needed for our simple case.
• Including projects we depend on. This is the trickiest bit we need to deal with. There are two aspects to consider - how we get the projects included, and how we configure them.
• Getting sources. We're going to use a git submodule for today, because everything is available from github. If this wasn't the case, we could instead use the DownloadProject approach.
• Configuring sources. There isn't a lot to configure, and thankfully these all support CMake, so we can simply tweak configurations and add the target compilation definition we need in our own top-level file.
• Downloading assets. Not doing this yet, but definitely something to consider rather than pulling the DirectX SDK samples when what I'm really interested in is the sample audio file.

To set up the dependencies, we simply do the following from the root as part of this change, and leave users or CMake to sort out how these should get updated.

> git submodule add ../../redis/hiredis.git 04/hiredis
> git submodule add ../../walbourn/directx-sdk-samples.git 04/directx-sdk-samples
> git submodule add ../../xiph/opus.git 04/opus
> git submodule add ../../xiph/opus-tools.git 04/opus-tools


Another aspect to remember was to remove the new submodules from the .gitignore file, as we want the file with the has reference there now.

Happy audio building!

Tags:  audio cmake

Home