Building Qt examples

Maya ships with Qt libraries and header files. These libraries may be different than other Qt libraries installed on your system. This is why it is important that the directory containing the headers packaged with Maya appear in your include path before other Qt header directories, and that the directory containing Maya's version of the libraries appears in your library path before other Qt library directories.

Use the qmake provided with the Maya devkit to build Qt plug-ins. qmake is located in the devkit's bin directory on all platforms.

Note:

Qt plug-ins must be built in the Visual Studio x64 Command Prompt on Windows. Use the Windows search function to find its location on your system.

Before building Qt examples, set up your environment according to the instructions in Setting up your build environment.

To build a Qt example:

Extract the Qt headers. See Qt headers and libraries for details.
Locate the plug-in you want to build. Plug-in examples are located in devkit's plug-ins directory. Qt example will have Qt in their names, and the files belonging to a specific example will be named similarly. For example, the helixQtCmd.cpp, helixQtCmd.h, and helixQtCmd.pro files belong to the helixQtCmd.
Create a directory named after your example and copy all the related files to that directory. For example, create the helixQtCmd directory and copy helixQtCmd.cpp, helixQtCmd.h, and helixQtCmd.pro to that directory.
Copy the qtconfig file, also located in the plug-ins directory, to the helixQtCmd directory.
Change directory to the example's directory. For example, change directory to the helixQtCmd directory.
Run qmake on the pro file to generate a makefile.

For example, on Linux or macOS, you would run:
```
 $DEVKIT_LOCATION/devkit/bin/qmake helixQtCmd.pro
```
On Windows, you would run:
```
 %DEVKIT_LOCATION%\devkit\qmake.exe helixQtCmd.pro
```
On macOS, the makefile will have the name of the project with the .mak extension added. For example, helixQtCmd.mak.

On Linux and Windows, the makefile will be named Makefile regardless of the name of the example.
Run make on the makefile to build the plug-in.

On Linux, run make –f Makefile

On macOS, run make –f helixQtCmd.mak

On Windows, run nmake /f Makefile

Debug build

All of the example Qt plug-ins are built in release (that is, non-debug) mode. To build them for debug, turn on qmake's debug configuration parameter by doing the following in your .pro file:

CONFIG += debug

That should be sufficient to build your plug-in for debug on Linux and OS X. Unfortunately, on Windows, the debug configuration setting does not just compile your plug-in with debugging information, but it also forces the plug-in to link with the debug versions of the Qt libraries. That makes the plug-in incompatible with Maya, which was linked using the release versions of the Qt libraries. Depending upon which Qt classes your plug-in uses, it may or may not load into Maya, but even if it does successfully load, it is unlikely to perform correctly since it will not have access to Maya's QCoreApplication or other Qt global values.To get around this, set the debug configuration parameter described above and build the intermediate makefiles using the following command, substituting the name of your plug-in for myPlugin:

nmake /f Makefile.qt myPlugin.mak

This generates, among other things, a .mak.Debug file for your plug-in (for example, myPlugin.mak.Debug). Edit that file, find the LIBS line, and replace all of the debug Qt libraries with their non-debug versions by removing the final d from their names. For example, in helixQtCmd.mak.Debug the LIBS line would initially look like this:

LIBS = /LIBPATH:..\..\lib ..\..\lib\OpenMaya.lib ..\..\lib\Foundation.lib ..\..\lib\OpenMayaUI.lib c:\qt-adsk-5.6.1\lib\QtGuid4.lib c:\qt-adsk-5.6.1\lib\QtCored4.lib`

You would replace QtGuid4.lib with QtGui4.lib, and QtCored4.lib with QtCore4.lib, leaving you with this:

LIBS = /LIBPATH:..\..\lib ..\..\lib\OpenMaya.lib ..\..\lib\Foundation.lib ..\..\lib\OpenMayaUI.lib c:\qt-adsk-5.6.1\lib\QtGui4.lib c:\qt-adsk-5.6.1\lib\QtCore4.lib`

Now use the modified .mak.Debug file to explicitly build your plug-in:

nmake /f myPlugin.mak.Debug debug\myPlugin.mll

This still leaves one potential problem area on Windows. Qt's QList template class provides inline methods which can create and destroy Qt objects. Because those methods are inlined, if they are called by plug-in code which has been built for debug, any objects created or deleted will use the memory allocator from the debug version of Microsoft's C Runtime Library. If the methods are called within Maya, they will use the release version of the C Runtime Library. Thus it is possible to get situations where objects are allocated within Maya using the release runtime library and deleted in the plug-in using the debug runtime library, or vice-versa. Since the release and debug versions of Microsoft's C Runtime Library are incompatible with each other, this can lead to crashes.

At the moment, QList is the only Qt class we are aware of which has this potential for failure, but other Qt template classes could exhibit similar problems. To date, the only known workarounds are either to avoid the use of Qt template classes in your code, or to only build your plug-in in release mode on Windows.