Viadeo Twitter Google Bookmarks ! Facebook Digg del.icio.us MySpace Yahoo MyWeb Blinklist Netvouz Reddit Simpy StumbleUpon Bookmarks Windows Live Favorites 
Logo Documentation Qt ·  Page d'accueil  ·  Toutes les classes  ·  Classes principales  ·  Annotées  ·  Classes groupées  ·  Modules  ·  Fonctions  · 

qmake Advanced Usage

Many qmake project files simply describe the sources and header files used by the project, using a list of name = value and name += value definitions. qmake also provides other operators, functions, and scopes that can be used to process the information supplied in variable declarations. These advanced features allow Makefiles to be generated for multiple platforms from a single project file.

Operators

In many project files, the assignment (=) and append (+=) operators can be used to include all the information about a project. The typical pattern of use is to assign a list of values to a variable, and append more values depending on the result of various tests. Since qmake defines certain variables using default values, it is sometimes necessary to use the removal (-=) operator to filter out values that are not required. The following operators can be used to manipulate the contents of variables.

The = operator assigns a value to a variable:

    TARGET = myapp

The above line sets the TARGET variable to myapp. This will overwrite any values previously set for TARGET with myapp.

The += operator appends a new value to the list of values in a variable:

    DEFINES += QT_DLL

The above line appends QT_DLL to the list of pre-processor defines to be put in the generated Makefile.

The -= operator removes a value from the list of values in a variable:

    DEFINES -= QT_DLL

The above line removes QT_DLL from the list of pre-processor defines to be put in the generated Makefile.

The *= operator adds a value to the list of values in a variable, but only if it is not already present. This prevents values from being included many times in a variable. For example:

    DEFINES *= QT_DLL

In the above line, QT_DLL will only be added to the list of pre-processor defines if it is not already defined. Note that the unique() function can also be used to ensure that a variables only contains one instance of each value.

The ~= operator replaces any values that match a regular expression with the specified value:

    DEFINES ~= s/QT_[DT].+/QT

In the above line, any values in the list that start with QT_D or QT_T are replaced with QT.

The $$ operator is used to extract the contents of a variable, and can be used to pass values between variables or supply them to functions:

    EVERYTHING = $$SOURCES $$HEADERS
    message("The project contains the following files:")
    message($$EVERYTHING)

Scopes

Scopes are similar to if statements in procedural programming languages. If a certain condition is true, the declarations inside the scope are processed.

Scopes and Conditions

A scope is written as a condition followed by a series of declarations contained within a pair of braces; for example:

    win32 {
        SOURCES += paintwidget_win.cpp
    }

The above code will add the paintwidget_win.cpp file to the sources listed in the generated Makefile if qmake is used on a Windows platform. If qmake is used on a platform other than Windows, the define will be ignored.

The conditions used in a given scope can also be negated to provide an alternative set of declarations that will be processed only if the original condition is false. For example, suppose we want to process something on all platforms except for Windows. We can achieve this by negating the scope like this:

    !win32 {
        SOURCES -= paintwidget_win.cpp
    }

Scopes can be nested to combine more than one condition. For instance, if you want to include a particular file for a certain platform only if debugging is enabled then you write the following:

    macx {
        debug {
            HEADERS += debugging.h
        }
    }

To save writing many nested scopes, you can nest scopes using the : operator. The nested scopes in the above example can be rewritten in the following way:

    macx:debug {
        HEADERS += debugging.h
    }

You may also use the : operator to perform single line conditional assignments; for example:

    win32:DEFINES += QT_DLL

The above line adds QT_DLL to the DEFINES variable only on the Windows platform. Generally, the : operator behaves like a logical AND operator, joining together a number of conditions, and requiring all of them to be true.

You can also provide alternative declarations to those within a scope by using an else scope. Each else scope is processed if the conditions for the preceding scopes are false. This allows you to write complex tests when combined with other scopes (separated by the : operator as above). For example:

    win32:xml {
        message(Building for Windows)
        SOURCES += xmlhandler_win.cpp
    } else:xml {
        SOURCES += xmlhandler.cpp
    } else {
        message("Unknown configuration")
    }

Configuration and Scopes

The values stored in the CONFIG variable are treated specially by qmake. Each of the possible values can be used as the condition for a scope. For example, the list of values held by CONFIG can be extended with the debug value:

    CONFIG += debug

As a result of this operation, any scopes that test for debug will be processed. We can use this feature to give the final executable an appropriate name:

    debug {
        TARGET = application-debug
    }

    release {
        TARGET = application
    }

This feature makes it easy to change the configuration for a project without losing all the custom settings that might be needed for a specific configuration. In the above code, the declarations in the first scope are processed, and the final executable will be called application-debug. However, if release is specified instead of debug, the declarations in the second scope are processed instead, and the final executable will be called application.

Since it is possible to put your own values on the CONFIG line, this provides you with a convenient way to customize project files and fine-tune the generated Makefiles.

Platform Scope Values

In addition to the win32, macx, and unix values used in many scope conditions, various other built-in platform and compiler-specific values can be tested with scopes. These are based on platform specifications provided in Qt's mkspecs directory. For example, the following lines from a project file show the current specification in use and test for the linux-g++ specification:

    message($$QMAKESPEC)

    linux-g++ {
        message(Linux)
    }

You can test for any other platform-compiler combination as long as a specification exists for it in the mkspecs directory.

Variables

Many of the variables used in project files are special variables that qmake uses when generating Makefiles, such as DEFINES, SOURCES, and HEADERS. It is possible for you to create variables for your own use; qmake creates new variables with a given name when it encounters an assignment to that name. For example:

    MY_VARIABLE = value

There are no restricitions on what you do to your own variables, as qmake will ignore them unless it needs to evaluate them when processing a scope.

You can also assign the value of a current variable to another variable by prefixing $$ to the variable name. For example:

    MY_DEFINES = $$DEFINES

Now the MY_DEFINES variable contains what is in the DEFINES variable at this point in the project file. This is also equivalent to:

    MY_DEFINES = $${DEFINES}

The second notation allows you to append the contents of the variable to another value without separating the two with a space. For example, the following will ensure that the final executable will be given a name that includes the project template being used:

    TARGET = myproject_$${TEMPLATE}

Variables can be used to store the contents of environment variables. These can be evaluated at the time that qmake is run, or included in the generated Makefile for evaluation when the project is built.

To obtain the contents of an environment value when qmake is run, use the $$(...) operator:

    DESTDIR = $$(PWD)
    message(The project will be installed in $$DESTDIR)

In the above assignment, the value of the PWD environment variable is read when the project file is processed.

To obtain the contents of an environment value at the time when the generated Makefile is processed, use the $(...) operator:

    DESTDIR = $$(PWD)
    message(The project will be installed in $$DESTDIR)

    DESTDIR = $(PWD)
    message(The project will be installed in the value of PWD)
    message(when the Makefile is processed.)

In the above assignment, the value of PWD is read immediately when the project file is processed, but $(PWD) is assigned to DESTDIR in the generated Makefile. This makes the build process more flexible as long as the environment variable is set correctly when the Makefile is processed.

The special $$[...] operator can be used to access various configuration options that were set when Qt was built:

    message(Qt version: $$[QT_VERSION])
    message(Qt is installed in $$[QT_INSTALL_PREFIX])
    message(Qt resources can be found in the following locations:)
    message(Documentation: $$[QT_INSTALL_DOCS])
    message(Header files: $$[QT_INSTALL_HEADERS])
    message(Libraries: $$[QT_INSTALL_LIBS])
    message(Binary files (executables): $$[QT_INSTALL_BINS])
    message(Plugins: $$[QT_INSTALL_PLUGINS])
    message(Data files: $$[QT_INSTALL_DATA])
    message(Translation files: $$[QT_INSTALL_TRANSLATIONS])
    message(Settings: $$[QT_INSTALL_SETTINGS])
    message(Examples: $$[QT_INSTALL_EXAMPLES])
    message(Demonstrations: $$[QT_INSTALL_DEMOS])

The variables accessible with this operator are typically used to enable third party plugins and components to be integrated with Qt. For example, a Qt Designer plugin can be installed alongside Qt Designer's built-in plugins if the following declaration is made in its project file:

    target.path = $$[QT_INSTALL_PLUGINS]/designer
    INSTALLS += target

Variable Processing Functions

qmake provides a selection of built-in functions to allow the contents of variables to be processed. These functions process the arguments supplied to them and return a value, or list of values, as a result. In order to assign a result to a variable, it is necessary to use the $$ operator with this type of function in the same way used to assign contents of one variable to another:

    HEADERS = model.h
    HEADERS += $$OTHER_HEADERS
    HEADERS = $$unique(HEADERS)

This type of function should be used on the right-hand side of assignments (i.e, as an operand).

It is possible to define your own functions for processing the contents of variables. The following example function takes a variable name as its only argument, extracts a list of values from the variable with the eval() built-in function, and compiles a list of files:

    defineReplace(headersAndSources) {
        variable = $$1
        names = $$eval($$variable)
        headers =
        sources =

        for(name, names) {
            header = $${name}.h
            exists($$header) {
                headers += $$header
            }
            source = $${name}.cpp
            exists($$source) {
                sources += $$source
            }
        }
        return($$headers $$sources)
    }

Conditional Functions

qmake provides built-in functions that can be used as conditions when writing scopes. These functions do not return a value, but instead indicate "success" or "failure":

    count(options, 2) {
        message(Both release and debug specified.)
    }

This type of function should be used in conditional expressions only.

It is possible to define your own functions to provide conditions for scopes. The following example tests whether each file in a list exists and returns true if they all exist, or false if not:

    defineTest(allFiles) {
        files = $$ARGS

        for(file, files) {
            !exists($$file) {
                return(false)
            }
        }
        return(true)
    }

Adding New Configuration Features

qmake lets you create your own features that can be included in project files by adding their names to the list of values specified by the CONFIG variable. Features are collections of custom functions and definitions in .prf files that can reside in one of many standard directories. The locations of these directories are defined in a number of places, and qmake checks each of them in the following order when it looks for .prf files:

  1. In a directory listed in the QMAKEFEATURES environment variable; this contains a colon-separated list of directories.
  2. In a directory listed in the QMAKEFEATURES property variable; this contains a colon-spearated list of directories.
  3. In a features directory beneath the project's root directory (where the .qmake.cache file is generated).
  4. In a features directory residing within a mkspecs directory. mkspecs directories can be located beneath any of the directories listed in the QMAKEPATH environment variable (a colon-separated list of directories). ($QMAKEPATH/mkspecs/<features>)
  5. In a features directory residing beneath the directory provided by the QMAKESPEC environment variable. ($QMAKESPEC/<features>)
  6. In a features directory residing in the data_install/mkspecs directory. (data_install/mkspecs/<features>)
  7. In a features directory that exists as a sibling of the directory specified by the QMAKESPEC environment variable. ($QMAKESPEC/../<features>)

The following features directories are searched for features files:

  1. features/unix, features/win32, or features/macx, depending on the platform in use
  2. features/

For example, consider the following assignment in a project file:

    CONFIG += myfeatures

With this addition to the CONFIG variable, qmake will search the locations listed above for the myfeatures.prf file after it has finished parsing your project file. On Unix systems, it will look for the following file:

  1. $QMAKEFEATURES/myfeatures.prf (for each directory listed in the QMAKEFEATURES environment variable)
  2. $$QMAKEFEATURES/myfeatures.prf (for each directory listed in the QMAKEFEATURES property variable)
  3. myfeatures.prf (in the project's root directory)
  4. $QMAKEPATH/mkspecs/features/unix/myfeatures.prf and $QMAKEPATH/mkspecs/features/myfeatures.prf (for each directory listed in the QMAKEPATH environment variable)
  5. $QMAKESPEC/features/unix/myfeatures.prf and $QMAKESPEC/features/myfeatures.prf
  6. data_install/mkspecs/features/unix/myfeatures.prf and data_install/mkspecs/features/myfeatures.prf
  7. $QMAKESPEC/../features/unix/myfeatures.prf and $QMAKESPEC/../features/myfeatures.prf

[Previous: Running qmake] [Contents] [Next: Using Precompiled Headers]

Publicité

Best Of

Actualités les plus lues

Semaine
Mois
Année
  1. « Quelque chose ne va vraiment pas avec les développeurs "modernes" », un développeur à "l'ancienne" critique la multiplication des bibliothèques 102
  2. Pourquoi les programmeurs sont-ils moins payés que les gestionnaires de programmes ? Manquent-ils de pouvoir de négociation ? 53
  3. «Le projet de loi des droits du développeur» : quelles conditions doivent remplir les entreprises pour que le développeur puisse réussir ? 73
  4. Les développeurs détestent-ils les antivirus ? Un programmeur manifeste sa haine envers ces solutions de sécurité 28
  5. Qt Commercial : Digia organise un webinar gratuit le 27 mars sur la conception d'interfaces utilisateur et d'applications avec le framework 0
  6. Quelles nouveautés de C++11 Visual C++ doit-il rapidement intégrer ? Donnez-nous votre avis 10
  7. 2017 : un quinquennat pour une nouvelle version du C++ ? Possible, selon Herb Sutter 11
Page suivante
  1. Linus Torvalds : le "C++ est un langage horrible", en justifiant le choix du C pour le système de gestion de version Git 100
  2. Comment prendre en compte l'utilisateur dans vos applications ? Pour un développeur, « 90 % des utilisateurs sont des idiots » 229
  3. Quel est LE livre que tout développeur doit lire absolument ? Celui qui vous a le plus marqué et inspiré 96
  4. Apple cède et s'engage à payer des droits à Nokia, le conflit des brevets entre les deux firmes s'achève 158
  5. Nokia porte à nouveau plainte contre Apple pour violation de sept nouveaux brevets 158
  6. « Quelque chose ne va vraiment pas avec les développeurs "modernes" », un développeur à "l'ancienne" critique la multiplication des bibliothèques 102
  7. Quel est le code dont vous êtes le plus fier ? Pourquoi l'avez-vous écrit ? Et pourquoi vous a-t-il donné autant de satisfaction ? 83
Page suivante

Le Qt Developer Network au hasard

Logo

Livre blanc de l'outillage de Qt Quick

Le Qt Developer Network est un réseau de développeurs Qt anglophone, où ils peuvent partager leur expérience sur le framework. Lire l'article.

Communauté

Ressources

Liens utiles

Contact

  • Vous souhaitez rejoindre la rédaction ou proposer un tutoriel, une traduction, une question... ? Postez dans le forum Contribuez ou contactez-nous par MP ou par email (voir en bas de page).

Qt dans le magazine

Cette page est une traduction d'une page de la documentation de Qt, écrite par Nokia Corporation and/or its subsidiary(-ies). Les éventuels problèmes résultant d'une mauvaise traduction ne sont pas imputables à Nokia. Qt 4.1
Copyright © 2012 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon, vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD.
Vous avez déniché une erreur ? Un bug ? Une redirection cassée ? Ou tout autre problème, quel qu'il soit ? Ou bien vous désirez participer à ce projet de traduction ? N'hésitez pas à nous contacter ou par MP !
 
 
 
 
Partenaires

Hébergement Web