Shulou(Shulou.com)06/02 Report--

At work, I feel that some of the contents of the pro file really do not understand, now learn it systematically. Here is a record to share and encourage.

For a better understanding, first create a simple project as a practice.

[1] create a pro file

1.1 New proDemo project. The steps are as follows: Qt Creator--- > New Project--- > Application-> Qt Widgets Application--- > name: proDemo (create path by yourself, local is F:\ Source\ proStudy)-> Class information remains unchanged-- > complete

1.2 extract pro files. Under the project directory, find the file named proDemo and type pro, as follows:

I don't understand? Ha ha ~ I do not understand, first study, pro file analysis is as follows:

[2] template variable

2.1 template variable TEMPLATE

The template variable function tells qmake exactly what kind of makefile to generate for this application. The following values are available for template variables to choose from:

[1] default value of app template variable. Create an application's makefile.

[2] lib builds the makefile of a library.

[3] vcapp creates an application's Visual Studio project file.

[4] vclib creates a VisualStudio project file for a library.

[5] subdirs this is a special template that creates a makefile that can enter a specific directory and generate makefile for a project file, and then call make for it.

From the above analysis, we can see that the value of template variables is different, the generated makefile file will change accordingly. So, the default is also the most commonly used app value, see below for the template.

2.2 app template

The app template tells qmake to generate a makefile for building an application.

When using this template, setting the following values of qmake system variables is valid. You can use them in your .pro files to specify specific information for your application.

HEADERS-list of all header files in the application.

SOURCES-list of all source files in the application.

FORMS-A list of all .ui files (generated by the Qt designer) in the application.

LEXSOURCES-list of all lex source files in the application.

YACCSOURCES-list of all yacc source files in the application.

TARGET-name of the executable application. The default value is the name of the project file. (if an extension is needed, it will be added automatically. )

DESTDIR-the directory where the executable program target is placed.

DEFINES-A list of additional preprocessor definitions required by the application.

INCLUDEPATH-an additional list of containing paths required by the application.

DEPENDPATH-the search path on which the application depends.

VPATH-find the search path for supplementary files.

DEF_FILE-only Windows needs: .def files to which the application connects.

RC_FILE-only Windows needs: the application's resource file.

RES_FILE-only Windows needs: the resource file to which the application connects.

You only need to use system variables that you already have a value for. For example, if you don't need any extra INCLUDEPATH, then you don't need to specify it, qmake will provide default values for the required system variables.

For example, the project pro file in the example above can also be written like this:

Note: if the entry is single-valued, such as template or the destination directory DESTDIR (the release directory of executable or binary files), we use "=", but if it is a multi-valued entry, we use "+ =" to add the existing entry value to this variable.

Using "=" replaces the original value with the new value. For example, if we write DEFINES = QT_DLL, all other DEFINES entry values will be deleted and replaced with QT_DLL.

2.3 lib template

The lib template tells qmake to generate a makefile to build a library. When using this template, a VERSION is supported in addition to the system variables mentioned in the app template.

You need to use them in .pro files that specify specific information for the library. VERSION-the version number of the target library. For example, 2.3.1.

2.4 subdirs template

The subdirs template tells qmake to generate a makefile that can go to a specific subdirectory and generate makefile for the project files in that directory and call make for it.

Only one system variable SUBDIRS can be recognized in this template. This variable contains a list of subdirectories containing project files to be processed. The name of the project file is the same as the subdirectory so that qmake can find it.

For example, if the subdirectory is "myapp", then the project file in this directory should be called myapp.pro.

[3] configuration variable CONFIG

The configuration variable CONFIG specifies the options to be used by the compiler and the libraries to be connected. Anything can be added to the configuration variable, but only the following options can be recognized by qmake.

3.1 Control compiler

The following options control which compiler flags are used:

Release-the application will be linked in release mode. If "debug" is specified, it will be ignored.

Debug-the application will be linked in debug mode (mutually exclusive with release).

Debug_and_release-the project is compiled in both debug and release mode.

Build_all-if debug_and_release mode is specified, the project is compiled in both debug and release mode by default.

Ordered-when using the subdirs template, this option specifies that subdirectories should be compiled in the order given.

Warn_on-the compiler outputs as many warnings as possible. If "warn_off" is specified, it will be ignored.

Warn_off-the compiler outputs as few warnings as possible (mutually exclusive with warn_on).

3.2 Serial type

The following options define the type of library / application to be linked:

Qt-the application is a Qt application, and the Qt library will be linked.

Thread-the application is a multithreaded application.

X11-an application is an X11 application or library.

Windows-for "app" templates only: the application is a window application under Windows.

Console-for "app" templates only: the application is a console application under Windows.

Dll-for "lib" templates only: the library is a shared library (dll).

Staticlib-for "lib" templates only: the library is a static library.

Plugin-for "lib" templates only: the library is a plug-in, which will enable the dll option to take effect.

For example, if your application uses the Qt library and you want to concatenate it into a debuggable multithreaded application, your project file should have the following line:

Note that you must use "+ =", not "=", otherwise qmake will not be able to use the settings for linking Qt correctly, such as getting the type of compiled Qt library.

Declare the QT library module

If the value of qt is included in the value of the CONFIG variable, qmake supports qt programs (because qmake can also be used in the compilation of non-qt programs). It is necessary to adjust some of the qt modules used in your program, and the QT variable serves this purpose. QT is used to declare some additional modules used, such as making xml and network modules effective by:

Note: by default, qt includes core and gui modules, so the above declaration simply adds xml and network modules to the default list.

For example, the following statement ignores the default module and causes an error when compiling the program source code:

If you want to compile a project that does not require a gui module, you need to use the "- =" operator to remove the inclusion.

For example, the following statement says that a small Qt project will be compiled

The following list shows the options available to the QT variable and explains the corresponding characteristics:

Core (included by default) QtCore module core module

Gui (included by default) QtGui module interface module

Network QtNetwork module supports network module

Opengl QtOpenGL module supports opengl image programming

Sql QtSql module supports sql database driver

Svg QtSvg module supports svg vector graphics

Xml QtXml module supports xml module

Qt3support Qt3Support module supports qt3 classes

Note: adding opengl to the QT variable is equivalent to adding the CONFIG variable.

So for Qt applications, it is not necessary to add opengl options to both the QT variable and the CONFIG variable.

3.4 about CONFIG (debug, debug | release) syntax

The CONFIG variable can define both debug and release, but only one is in active (when both mutually exclusive values appear, the last set is in the active state)

What does it mean? How do you understand it? Please read as follows:

As written above, release is in the active state. Nonsense! How do you know? Mm-hmm? If you don't believe me, let's test it with the above project.

[1] restore the test site. Delete the directories and files of the same level of the project folder proDemo (in order to verify the accuracy, restore the test site first, the following similar practice has the same meaning).

[2] modify the content. Change the pro type file in the project to the following:

[3] compile and build. First qmake the project, and then build it.

OK, complete the test operation. The exciting time has come! At this point, we will find that the proDemo sibling directory generated the appFile folder.

Open this folder and find two files: proDemo.exe and proDemo.exe.embed.manifest

It's broken! From the perspective of the pro file, our debug and release versions generate the same target file name (that is, the target value). What should I do? To verify that it is the release version of the executable program!

I'll tell you what! We searched for the * pdb file (a file that must be generated by debugging the debug version) in the parent directory, that is, the proStudy folder, but did not find it. OK! That means it's Release.

In fact, another way, we will find that the proDemo project folder under the same directory will also generate a build-proDemo-Desktop_Qt_5_3_MSVC2010_OpenGL_32bit-Debug name folder (explain one point: just build the program when the QT Creator mode is Debug), and this folder will have debug and release two folders, you will find that the debug file is empty, and the release folder has content. This also shows that what was just generated is the release version.

However, the above writing method, debug and release can pass the test, and reading is more difficult, anyway, I always feel too confusing, how to deal with it? It is recommended that it be written as follows:

In this case, let's analyze it again:

[1] restore the scene. Empty all folders except proDemo in the proDemo project directory (ditto).

[2] switch mode. Switch between Debug and Release versions:

[3] compile and build. Execute qmake individually, build it, run it again, and you can see the same form:

Although it looks like the same form, it is important to understand that it is two completely different versions of the application.

Now look at the two extra folders under the proDemo directory: demo_Debug and demo_Release. In their respective directories, you can find the executable programs proDemo_Debug and proDemo_Release, which are just two forms applications.

At the same time, you will find that the appFile folder is no longer generated, which can also verify the difference between "=" and "+ =" after DESTDIR.

So, what does the syntax of CONFIG (debug, debug | release) mean?

Note: two parameters, the former is the option to determine the active, and the latter is a collection of mutually exclusive options.

Does some people think it's so troublesome? In the above example, we generate two versions of the application, and we switch the Qt Creator build mode, so we want to generate it directly?

You can add the option build_all directly. For example, you can change the pro file to something like this:

Then empty the project folder other directories at the same level, and then qmake, after compilation, you can see that without switching Qt Creator, we also generate two versions of the executable program at the same time.

[3] Qt Creator creates the pro file of the project

The default pro files for different types of projects created by Qt Creator are listed below, for more information:

Create a new proDemo1 project (Note: template selection, Project: application; Qt Widgets Application). The steps are as follows: Qt Creator--- > New Project--- > Application-> Qt Widgets Application--- > name: proDemo1 (create path by yourself, local is F:\ Source\ proStudy)-- > Class information remains unchanged-- > complete. The corresponding pro file is as follows:

This pro file is actually the same as the first picture in this article. Because the project is the same, the default pro file is the same.

3.2 create a new proDemo2 project (Note: template selection, Project: application; Qt Quick Application). The steps are as follows: Qt Creator--- > New Project--- > Application-> Qt Quick Application--- > name: proDemo2 (create path by yourself, local is F:\ Source\ proStudy)-- > Qt Quick component set: Qt Quick Controls1.2--- > complete. The corresponding pro file is as follows:

This pro file introduces files of type pri using include.

Create a new proDemo3 project (Note: template selection, project: application; Qt console application). The steps are as follows: Qt Creator--- > New Project--- > Application-> Qt console Application-- > name: proDemo3 (create path is drawn up by yourself, local is F:\ Source\ proStudy)-- > Class information remains unchanged-- > complete. The corresponding pro file is as follows:

This pro file removes the default app_bundle entry of the CONFIG configuration variable because it is a console application.

3.4New proDemo4 project (Note: template selection, project: library; C++ library). The steps are as follows: Qt Creator--- > New Project--- > Library-- > C++ Library-- > name: proDemo4 (the creation path is drawn up by yourself, and the local name is F:\ Source\ proStudy)-- > Type: shared library-- > other items default-> complete. The corresponding pro file is as follows:

This pro file adds control of the unix environment.

3.5 New proDemo5 project (Note: template selection, project: library; C++ library). The steps are as follows: Qt Creator--- > New Project--- > Library-- > C++ Library-- > name: proDemo5 (the creation path is drawn up by yourself, local is F:\ Source\ proStudy)-- > Type: static link library-> other items default-> complete. The corresponding pro file is as follows:

The biggest difference between this pro file and the 3. 4 project is that the CONFIG value is added to the configuration variable, because the project type is selected as a static link library.

3.6New proDemo6 project (Note: template selection, project: library; C++ library). The steps are as follows: Qt Creator--- > New Project--- > Library-- > C++ Library-- > name: proDemo6 (the creation path is drawn up by yourself, local is F:\ Source\ proStudy)-- > Type: Qt Plugin--- > other items default-> complete. The corresponding pro file is as follows:

This pro file adds other file OTHER_FILES configuration variables, and the configuration variable CONFIG adds the plugin value because the project type is selected as Qt Plugin.

3.7New proDemo7 project (Note: template selection, project: other projects; Qt unit test). The steps are as follows: Qt Creator--- > New Project--- > other projects-- > Qt unit test-- > name: proDemo7 (create path by yourself, local is F:\ Source\ proStudy)-- > other items default-> complete. The corresponding pro file is as follows:

This pro file adds the testlib value to the QT variable.

Create a new proDemo8 project (Note: template selection, project: other projects; Qt4 designer custom controls). The steps are as follows: Qt Creator--- > New Project--- > other projects-- > Qt4 designer custom controls-- > name: proDemo8 (create path by yourself, local is F:\ Source\ proStudy)-- > control class: customControl--- > other items all default-> complete. The corresponding pro file is as follows:

In this pro file, add the value designer for the QT variable when the Qt version is greater than 4.0.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.