Today, qmake is the official, primary build tool for Qt; for applications and framework alike. The tool generates platform appropriate Makefiles, project files for IDEs, and runs tools for code generation (supporting widget ui files, meta-object classes for QObjects, and resource files). Replacing qmake has been a long time coming, there’s probably been discussion concerning it’s potential successor longer than I’ve been programming in Qt! Almost a decade ago, there was a blog post detailing the neccessary criteria for potential replacements. The main points were as follows:

1. Avoid a “proprietary” language
   • Promote good IDE integration
   • Build projects directly
   • Support for distributed build systems
   • Support cross-compiling
   • Support pkg-config
   • Generate deployment packages / installers
   • Provide configuration of projects

First officially introduced in early 2012, Qbs was intended to be a replacement for qmake. Introduced in the wake of QML, it naturally adopted a similar declarative Javascript syntax. Thus, satisying criteria #1. Reviewing the list of criteria, Qbs satisfied the majority of them. Over the following six years the tool continued to mature, receiving regular releases alongside the Qt framework and Qt Creator IDEs. Ask the right Qt Company developer during the annual Qt World Summit, and you may have even heard that Qbs was going to be the defacto build tool for Qt 6.

Meanwhile, many projects were adopting CMake as the build tool of choice. CMake is a cross-platform build system, much like qmake. First released back in 2000, it’s an open-source project, of which KitWare is perhaps the most visible contributor. The earliest mention of Qt I can find in CMake’s blog goes way back to July 2006 for the 2.4.2 release. The occasion for this event was KDE had chosen CMake as it’s build system, a very large, complex project to support. CMake support for Qt has continued to improve over time, to the point where it’s included in the Qt Creator IDE alongside Qbs. Anecdotally, when I encounter libraries or applications built with Qt, I find they’re built with CMake far more frequently than qmake or Qbs.

When we evaluated potential build tools at my current employer back in 2013, we considered the complexity of our product, community support / adoption for the build tool, and available IDE support. It was more important for a candidate to have been battle tested by large projects, than for it to be a perfect tool. While we make extensive use of Qt in our platform, there are significant portions that are vanilla, modern C++. We did not want to force non-Qt developers to deal with the additional cognitive overload of tooling / environment configuration that was irrelevant to their work. Developers focusing on areas other than the application platform wouldn’t need the additional tooling, libraries, and licenses that come with commercial Qt development. It needed to not only support Qt, but provide reasonable integration for RTI Connext DDS, and other 3rd party libraries / frameworks. The ease of generating sources from IDL in CMake was something that impressed us early on, as demonstrated in a recent post. After a short period of R&D, it was quickly apparent that CMake gave us what we needed in a build system.

I’m pretty happy with the outcome of this bet, and I predict the Qt Project will be as well. CMake has come really far in the past five years. In particular, I’m especially proud of a build system refactor we undertook earlier this year, where adopting Modern CMake practices greatly simplified, and optimized, the development experience with our platform. Our other big dependency, RTI Connext DDS, has begun providing CMake modules out of the box, further simplifying our work. Seeing these improvements in CMake 3.0 and beyond, I suspect Qt Company realized that the community had already voted with their time, energy, and adoption of CMake. Qt Company could choose to create their own bespoke build system, or that same effort could instead be put towards continuing to push the Qt Framework forward. I’m excited to see where this change of focus leads, and look forward to building Qt without needing to bootstrap qmake.

CMake is an open-source, cross-platform family of tools designed to build, test and package software (https://cmake.org). Qt has excellent support for CMake, although a few holes in the documentation can make adoption a bit challenging (Presenting an opportunity for future blog posts on the topic!). Modern CMake is set of best practices that as best I can tell are documented everywhere and nowhere online. There is no single authoritative source on the subject at this time, but it’s easy to find talks and blogs that seem to come to a general consensus on the do’s and don’ts.

RTI provides official CMake modules, which are made available to our project via the following lines in the top-level CMakeLists.txt. This offers an immediate improvement over our hardcoded support, for a single platform, in the prior qmake project file. Complete documentation on the capabilities of these CMake modules can be found within the headers of the two cmake files at $NDDSHOME/resource/cmake.

find_package(RTIConnextDDS)
find_package(RTICodeGenerator)

The headers, libraries, and compile defitions are then explicitly added as dependencies to the “common” project. I’ve created this project to encompass the responsibilities of the old dds.pri, the generation of sources from our sensor.idl file. “common” is both project name and the name of the CMake target, a static library which will be used by all three example applications.

target_link_libraries(common
  PUBLIC ${CONNEXTDDS_CPP2_API_LIBRARIES_RELEASE_SHARED}
)

target_include_directories(common
  PUBLIC ${PROJECT_BINARY_DIR}
  PUBLIC ${PROJECT_SOURCE_DIR}
  PUBLIC ${CONNEXTDDS_INCLUDE_DIRS}
)

target_compile_definitions(common
  PUBLIC RTI_UNIX
  PUBLIC RTI_LINUX
  PUBLIC RTI_64BIT
)

All of this work gets brought into the individual examples via the following. Let’s say that “example” is the project name of a Qt application. Using target_link_libraries we can instruct CMake to figure out what dependencies to bring along for the ride. In this case, anything marked PUBLIC from “common”.

target_link_libraries(example
  common
)

The greatest advantage to our use of CMake is the reduction from the whole of dds.pri to the following 15 lines. This can be leveraged to great effect when generating sources from multiple IDL files. Simply loop over the custom command in a macro with a list of IDL to generate the needed source files.

set(GENERATED_SOURCES
  ${PROJECT_BINARY_DIR}/sensor.cxx
  ${PROJECT_BINARY_DIR}/sensorImpl.cxx
  ${PROJECT_BINARY_DIR}/sensorImplPlugin.cxx
 )

add_custom_command(OUTPUT ${GENERATED_SOURCES}
  COMMAND ${RTICODEGEN} -language C++11 -d ${PROJECT_BINARY_DIR} ${PROJECT_SOURCE_DIR}/sensor.idl
  WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
  DEPENDS ${PROJECT_SOURCE_DIR}/sensor.idl
)

set_source_files_properties(${GENERATED_SOURCES} PROPERTIES GENERATED TRUE)

add_library(common
  ${GENERATED_SOURCES}
)

To build the project, we’ll assume that Qt is in your PATH. The follwing commands effectively replace qmake and make.

cmake -DCONNEXTDDS_ARCH=x64Linux3gcc5.4.0 -DCMAKE_MODULE_PATH=$NDDSHOME/resource/cmake -DRTICODEGEN_DIR=$NDDSHOME/bin .. 
cmake --build .

In my opinion, this results in a cleaner project view and better management of shared dependencies.

As an open standard, there are a number of implementations to pick and choose from. OpenDDS, available on GitHub, being the easiest to get ahold of. Several commercial implementations exist by vendors such as ADLINK / PrismTech, TwinOaks Computing, and RTI. Some even offer a “community edition” for open source projects. Only small changes to the qmake project file should be neccessary to port to another DDS implementations. As such, I would encourage anyone familiar with (and having access to) these other implementations to fork the GitHub project and test this assumption.

The API is defined for popular languages such as Java, C, C++, C#, as well as less popular ones such as Ada. The example as written by the folks at Qt Company demonstrates what RTI calls the “Traditional C++ API”. It’s very much “C-with-classes”, throwing around pointers, getting return codes, manually allocating memory. In this blog post we will migrate the examples to the C++ PSM (Platform Specific Module), the characteristics of which are similar to Qt C++. Entities such as participants, publishers, subscribers are now all reference types, while the generated classes from IDL are value types.

To demonstrate how this all impacts application code, I’ve further modified the GitHub fork of the IoT blog example. Changes pertinent to this post can be found at the following GitHub release. The first thing you’re likely to notice, no more mucking about with pointers and memory allocation! DDS entities can be created as shown here, and passed around by reference. We can make use of retain / release, similar to Objective C / Cocoa on iOS, to keep entities around even if they fall out of scope.

const DDS_DomainId_t domainId = 0;
dds::domain::DomainParticipant participant(domainId);
if (dds::core::null == participant) {
    qDebug() << "Could not create participant.";
    return -1;
}

dds::pub::Publisher publisher(participant);
if (dds::core::null == publisher) {
    qDebug() << "Could not create publisher.";
    return -2;
}

std::string topic_name = "Sensor Information";
dds::topic::Topic<sensor_information> topic(participant, topic_name);
if (dds::core::null == topic) {
    qDebug() << "Could not create topic.";
    return -3;
}

dds::pub::DataWriter<sensor_information> writer(publisher, topic);
if (dds::core::null == writer) {
    qDebug() << "Could not create writer.";
    return -4;
}

Generated types on the other hand, are now treated as value types. Member variables are modified using accessor methods.

// Create real data
sensor_information sensorInformation;
sensorInformation.ID("Foobidoo");
sensorInformation.ambientTemperature(12.);
// As sensors have a unique ID, register each sensor to reuse data
dds::core::InstanceHandle sensorHandle = writer.register_instance(sensorInformation);

// Send data twice within a one second interval
writer.write(sensorInformation, sensorHandle);

I cheated a tiny bit here, making use of an RTI specific function. When porting to other implementations of DDS, I’m sure a std::this_thread::sleep_for() will suffice.

dds::core::Duration send_period{1,0};
rti::util::sleep(send_period);

Another nice quality of life improvement, generated types implement the stream operator, such that you can cout the contents of a sample. In the case of the blog example, this simplified the qDebug() portion.

QDebug operator<<(QDebug d, const sensor_information &sensor)
{
    std::ostringstream stream;
    stream << sensor;

    d << "Sensor( " << QString::fromStdString(stream.str()) << ")";
    return d;
}

When it came to modifying the QML example, I skipped implementing error checking for the sake of showing a greatly simplified initialization. A 50 line init method is replaced by 6 additional lines in the constructor. In production code, it would be desirable to test created entities against dds::core::null to see if they were succesfully constructed. Though not demonstrated here, the Modern C++ API will now also throw exceptions for certain illegal operations. I leave it as an exercise to the reader to investigate the relevant documentation.

SensorInformation::SensorInformation(QObject *parent) :
    QObject(parent),
    m_participant(domainId),
    m_publisher(m_participant),
    m_topic(m_participant, "Sensor Information"),
    m_writer(m_publisher, m_topic)
{
    // Create real data
    m_id = QUuid::createUuid().toString().mid(1, 8);
    m_info.ID(m_id.toStdString());
}

I think you’ll agree the migrated application code is not only an easier read, but far less risky to implement. If you have time, pull down the code and give it a go. It works on my machine, as the tired refrain goes. Having demonstrated the RTI Modern C++ API, aka DDS PSM C++, I’ve got one more post and code change I’d like to make before leaving well enough alone.

The release linked here should succesfully compile and run in Ubuntu 16.04 LTS. By convention, all DDS libraries / headers are located in a path relative to the NDDSHOME environment variable. As such, the qmake project files were edited to accomodate the various path and filename changes.

RTIDDS_PREFIX = $$(NDDSHOME)
RTIDDS_VERSION = x64Linux3gcc5.4.0

The library names also required some editing. Note that the library names end with a ‘d’ suffix, indicating we’re linking to the shared, debug libraries. This is an area for potential improvement in future iterations.

LIBS += -L$${RTIDDS_PREFIX}/lib/$${RTIDDS_VERSION} -lnddscd -lnddscppd -lnddscored

In Linux we require several definitions to keep the compiler happy. That last one must be swapped out in order to build a 32 bit binary, but as I’m running this on a modern desktop I’m not too worried about it.

DEFINES += RTI_UNIX RTI_LINUX RTI_64BIT

The original example was running the latest Qt release (5.11), while I’m back a few releases in stability land with Qt 5.9 LTS. To get the application running I cranked down the version numbers on several of the imports.

import QtQuick 2.9
import QtQuick.Window 2.2
import QtQuick.Layouts 1.3
import QtQuick.Controls 2.2

One last item requiring change: the commands for generating IDL sources caused make to fail. As an example, the original line looked like:

ddsplugingen.commands = echo "Additional Source(Plugin): ${QMAKE_FILE_NAME}"

The ( ) around Plugin caused /bin/sh to exit, requiring us to either escape or remove the offending characters.

ddsplugingen.commands = echo "Additional Source Plugin: ${QMAKE_FILE_NAME}"

With these minor changes, the examples succesfully compile and run in Ubuntu 16.04 LTS! Having established a baseline for development, we can move onto more exciting changes in future blog posts.

My own contribution to this event came in the form of a talk on Building a Human Machine Interface for the Medical IoT. Enough folks submitted talk abstracts for Qt in medical that we effectively got our own session track in room A05 on the second day. It was great to have an audience of folks already invested in the medical space, and at least from my view up front the talk seemed well received. The talk covered the basics of the medical IoT platform we’re creating, and into all the ways we’re using Qt to create clinical apps for the Hospital, as well as how we’re extending the framework to support novel features.

I’ve uploaded the slide deck. My thanks to DocBox for sponsoring the trip out to Berlin, and my wife for lending me out for the week.

Using the Ubuntu GNU/Linux distribution and Qt application framework, we will demonstrate a theoretical app platform for an IIoT device. This theoretical app platform will be modeled after production systems using open source software in the automotive and medical industries. We’ll explore the rationale for creating such a platform, then briefly introduce the Qt application framework, and create an example app from scratch. Finally, we will package and deploy this app to our theoretical device for a live demo.

The demo code for the system UI and demo application can (soon) be found at my VTCC 2017 GitHub repo. The slide deck is also available online.

I’m happy to announce that in addition to the VTCC talk, I will be speaking at the Qt World Summit in Berlin, Germany!