Deployment preparation

The center piece of our application is the cm-ui executable. This is the file that gets launched by the end user and that opens graphical windows and orchestrates all the fancy stuff we’ve written. When we run the cm-ui project in Qt Creator, it opens the executable file for us and everything works perfectly. However, distributing our application to another user is unfortunately more complicated than simply plonking a copy of the executable on their machine and launching it.

Our executable has a variety of dependencies that need to be in place in order for it to run. A prime example of a dependency is our very own cm-lib library. Pretty much all of our business logic is hidden away in there, and without that functionality, our UI can’t do much. The implementation details for dependency resolution across the various operating systems are complex and well beyond the scope of this book. However, the fundamental requirements of our application are the same, irrespective of the platform.

There are four categories of dependency that we need to consider and ensure that they are in place on our target user’s machine in order for our application to function:

• Item 1: Custom libraries we’ve written or added to our solution manually. In this case, it is only the cm-lib library that we need to worry about.
• Item 2: The parts of the Qt framework that our application links to, both directly and indirectly. We already know some of these through the modules we’ve added to our .pro files, for example, the qml and quick modules require the QtQml and QtQuick components.
• Item 3: Any internal dependencies of the Qt framework itself. This includes platform-specific files, resources for the QML subsystem, and third-party libraries such as sqlite or openssl.
• Item 4: Any libraries required by the C++ compiler we have built the application with.

We’ve already worked extensively with item 1, back in Chapter 2, Project Structure, we put a lot of work into controlling exactly where that output goes. We haven’t really needed to worry about items 2 and 3, because we have a full installation of the Qt Framework in our development machine and that takes care of everything for us. Similarly, item 4 is dictated by the kit we use, and if we have a compiler available on our machine, it follows that we have the libraries it needs too.

Identifying exactly what we need to copy for our end users (who more than likely don’t have Qt or other development tools installed) can be an excruciating exercise. Even once we’ve done that, packaging everything up into a neat package or installer that is simple for the user to run can be a project in itself. Fortunately, Qt offers us some help in the form of bundled tools.

Linux and macOS X have a concept of application packages, whereby the application executable and all dependencies can be rolled up together into a single file that can then be easily distributed and launched at the click of a button. Windows is a bit more freestyle and if we want to bundle all of our files into a single installable file, we need to do a bit more work, but again, Qt comes to the rescue and comes with the fantastic Qt Installer Framework that simplifies it for us.

Let’s take a look at each operating system in turn and produce an application package or installer for each.