Translation of qmake document (4) building common project types

Translate the qmake document directory

 

This chapter Original English document: http://qt-project.org/doc/qt-5/qmake-common-projects.html

 

Build Common project typesThis chapter describes how to set qmake project files for three common project types: QT-based applications, libraries, and plug-ins. Although a large number of Identical variables are used for all project types, each of them uses project-specific variables to customize output files. The platform-specific variables are not described here. For more details, see QT for Windows-deployment and QT for Mac OS X. Bind an applicationThe app template tells qmake to generate the makefile of the application to be built. With this template, you can use any of the following options to add the makefile to the config variable definition to specify the application type:

Option	Description
Windows	This application is a window GUI application.
Console	Limited to application templates: this application is a Windows console application
Testcase	The application is an automated test

When this template is used, the following qmake system variables can be identified. You can use these variables in the. Pro file to specify information related to the application. Headers-List of application header files. Sources-List of application C ++ source files. Forms-List of application UI files (created using QT designer) lexsources-application Lex source file list yaccsources-application YACC source file list target-application executable file name. It is the name of the project file by default. (If the extension is required, it will be automatically added) destdir-the folder that stores the target executable program. Defines-List of additional pre-processing definitions required by the application. Includepath-List of additional paths required by the application. Dependpath-the search path on which the application depends. Vpath-used to find the search path of the provided file def_file-used only for Windows: The. Def file to be linked by the application res_file-used only for Windows: The resource file of the application. Res_file-used only for Windows: resource files to be linked by the application. You only need to use system variables with values. For example, if you do not have an extra includepath, you do not need to specify it. Qmake automatically adds the required default values. A sample project file may be as follows:

TEMPLATE = appDESTDIR  = c:/helloappHEADERS += hello.hSOURCES += hello.cppSOURCES += main.cppDEFINES += USE_MY_STUFFCONFIG  += release

Because these items are single-value items, such as templates or target directories, we use "=", but for multi-value items, we use "+ =" to add them to existing type items. Use "=" to replace the value of the variable with the new value. For example, if we write defines = use_my_stuff in this way, all other definitions will be deleted to build a test case. A test case project is used as an app project for automatic test run. By adding testcase to the config variable, you can mark any app as a test case. For the testcase project, qmake inserts a check target in the generated makefile. The target will run the application. If it terminates exit code equal to 0, this test is considered to pass. Check that the target will pass the automatic recursion subdirs project. This means that it may issue a command to run a complete test suite from within the subdirs project. Check that the target running may be customized by some makefile variables. These variables are

Variable	Description
Testunner	Add a command or shell snippet before each test command. For example, use-case is a "timeout" used to terminate a test if it is not completed within a specified time period.
Testargs	Each additional parameter appended to each test command. For example, it may be useful to pass additional parameters from the test to set the output file and format. (Like the-O filename and format options supported by qtestlib)

Note: These variables must be set when the make tool is called instead of in the. Pro file. Most make tools support setting makefile variables directly on the command line.

# Run tests through test-wrapper and use xunitxml output format.# In this example, test-wrapper is a fictional wrapper script which terminates# a test if it does not complete within the amount of seconds set by "--timeout".# The "-o result.xml,xunitxml" options are interpreted by QTestLib.make check TESTRUNNER="test-wrapper --timeout 120" TESTARGS="-o result.xml,xunitxml"

The following configuration can be used in the config option of the test case project to further customize the settings.

Option	Description
Insignificat_test	The exit code during the check will be ignored

Qtest or testcase is often used for testing, but this does not require config + = testcase and make check. The only major requirement is that the test program successfully exits the Code with zero exit. Non-zero exit indicates that the Code fails. Build DatabaseThe LIB template tells qmqke to generate a makefile that will build a library. When this template is used, besides the system variables supported by the app template, the version variables are also supported. Use these variables in your. Pro file to specify information about the library. When using the Lib template, the following options can be added to the config variable to determine the type of the build Library:

Option	Description
DLL	This library is a shared library (DLL ).
Staticlib	This library is a static library.
Plugin	This library is a plug-in.

You can also define the options below to provide additional library information. Version-version number of the target database. For example, the target file name of database 2.3.1 depends on the platform. For example, in X11 and Mac OS X, the Library name uses lib as the prefix. On Windows, the file name has no prefix. Build plug-insUse the Lib library to build the plug-in, as described in the previous chapter. This tells qmake to generate a makefile for the project and build an appropriate plug-in for each platform, usually in the form of a library. Like a common library, the version variable specifies the information of the plug-in.

Version-version number of the target database, for example, 2.3.1.

 

Build the QT designer plug-inUse a specific set of configuration settings to build the QT designer plug-in. These configurations depend on the system's QT configuration. For convenience, you can add a designer in the QT variable to start these settings. For example:

QT +=  widgets designer

For more examples of plug-in-based projects, see QT designer examples

Build and install in debug and release Modes

Sometimes, it is necessary to build a project in both Debug and release modes. Although the config variable can save both Debug and release options, only the last specified option will be applied.

Built in two modes

To start a project in both modes, you must add the debug_and_release option to the config variable:

CONFIG += debug_and_releaseCONFIG(debug, debug|release) {    TARGET = debug_binary} else {    TARGET = release_binary}

 

The above code snippet scope modifies the build target in each mode to ensure that the result target has different names. Provide different names for the target to ensure that the two are not overwritten.

When qmake is used to process project files. It generates a makefile rule to allow projects to be built in two modes. You can call the following method:

make all

 

In the project file, you can add the build_all option to the config variable to ensure that the project is generated in two modes by default:

CONFIG += build_all

This allows makefile to be processed by default rules.

make

Install in two modes

The build_all option ensures that the installation is directed to the two target versions when the installation rule is called:

make install

You can also customize the name of the build Target Based on the target platform. For example, a library or plug-in can use different naming conventions on Windows and UNIX platforms.

CONFIG(debug, debug|release) {    mac: TARGET = $$join(TARGET,,,_debug)    win32: TARGET = $$join(TARGET,,d)}

The default behavior of the code snippet above is to modify the target name generated by building in debug mode. You can add the else statement to the scope for doing the same in the release mode. The target name is not modified and remains unchanged.

Translation of qmake document (4) building common project types