qmake-manual-7.html

QT 下载资料仅供参考

<p><em>qmake</em> recognizes the following functions:</p>
<h4><a name="5-1"></a>include( filename )</h4>
<p>This function will include the contents of <em>filename</em> into the current project at the point where was included. The function succeeds if <em>filename</em> was included, otherwise it fails. You can check the return value of this function using a scope.</p>
<p>For example:</p>
<pre>
include( shared.pri )
OPTIONS = standard custom
!include( options.pri ) {
	message( "No custom build options specified" )
	OPTIONS -= custom
}
</pre>
<h4><a name="5-2"></a>exists( file )</h4>
<p>This function will test if <em>file</em> exists. If the file exists, then it will succeed; otherwise it will fail. You can specify a regular expression in file and it will succeed if any file matches the regular expression specified.</p>
<p>For example:</p>
<pre>
exists( $(QTDIR)/lib/qt-mt* ) {
      message( "Configuring for multi-threaded Qt..." )
      CONFIG += thread
}
</pre>
<h4><a name="5-3"></a>contains( variablename, value )</h4>
<p>This function will succeed if the variable <em>variablename</em> contains the value <em>value</em>. You can check the return value of this function using a scope.</p>
<p>For example:</p>
<pre>
contains( drivers, network ) {
	# drivers contains 'network'
	message( "Configuring for network build..." )
	HEADERS += network.h
	SOURCES += network.cpp
}
</pre>
<h4><a name="5-4"></a>count( variablename, number )</h4>
<p>This function will succeed if the variable <em>variablename</em> contains <em>number</em> elements, otherwise it will fail. You can check the return value of this function using a scope.</p>
<p>For example:</p>
<pre>
MYVAR = one two three
count( MYVAR, 3 ) {
	# always true
}
</pre>
<h4><a name="5-5"></a>infile( filename, var, val )</h4>
<p>This function will succeed if the file <em>filename</em> (when parsed by qmake itself) contains the variable <em>var</em> with a value of <em>val</em>. You may also not pass in a third argument (<em>val</em>) and the function will only test if <em>var</em> has been assigned to in the file.</p>
<h4><a name="5-6"></a>isEmpty( variablename )</h4>
<p>This function will succeed if the variable <em>variablename</em> is empty (same as <tt>count(variable, 0)</tt>).</p>
<h4><a name="5-7"></a>system( command )</h4>
<p>This function will execute <tt>command</tt> in a secondary shell and will succeed if the command exits with an exit status of 1. You can check the return value of this function using a scope.</p>
<p>For example:</p>
<pre>
  system(ls /bin):HAS_BIN=FALSE
</pre>
<h4><a name="5-8"></a>message( string )</h4>
<p>This function will always succeed, and will display the given <em>string</em> to the user.</p>
<h4><a name="5-9"></a>error( string )</h4>
<p>This function will never return a value. It will display the given <em>string</em> to the user, and then exit <em>qmake</em>. This function should only be used for very fatal configurations.</p>
<p>For example:</p>
<pre>
  release:debug:error(You can't have release and debug at the same time!)
</pre>
<a name="Environment"></a><h3><a name="6"></a>Environment Variables and Configuration</h3>
<a name="QMAKESPEC"></a><h4><a name="6-1"></a>QMAKESPEC</h4>
<p><em>qmake</em> requires a platform and compiler description file which contains many default values used to generate appropriate makefiles. The standard Qt distribution comes with many of these files, located in the 'mkspecs' subdirectory of the Qt installation.</p>
<p>The QMAKESPEC environment variable can contain any of the following:</p>
<ul><li><p>A complete path to a directory containing a qmake.conf file. In this case <em>qmake</em> will open the qmake.conf file from within that directory. If the file does not exist, <em>qmake</em> will exit with an error.</p>
<li><p>The name of a platform-compiler combination. In this case, <em>qmake</em> will search in the directory specified by the QTDIR environment variable.</p>
</ul><p>Note: the QMAKESPEC path will automatically be added to the <a href="qmake-manual-7.html#INCLUDEPATH">INCLUDEPATH</a> system variable.</p>
<a name="INSTALLS"></a><h4><a name="6-2"></a>INSTALLS</h4>
<p>It is common on UNIX to be able to install from the same utility as you build with (e.g make install). For this <em>qmake</em> has introduce the concept of an install set. The notation for this is quite simple, first you fill in an "object" in qmake for example:</p>
<pre>
  documentation.path = /usr/local/program/doc
  documentation.files = docs/*
</pre>
<p>In this way you are telling <em>qmake</em> several things about this install, first that you plan to install to /usr/local/program/doc (the path member), second that you plan to copy everything in the docs directory. Once this is done you may insert it in the install list:</p>
<pre>
  INSTALLS += documentation
</pre>
<p>Now <em>qmake</em> will take over making sure the correct things are copied to the specified places. If however you require greater control you may use the 'extra' member of the object:</p>
<pre>
  unix:documentation.extra = create_docs; mv master.doc toc.doc
</pre>
<p>Then qmake will run the things in extra (this is of course platform specific, so you may need to test for your platform first, this case we test for unix). Then it will do the normal processings of the files member. Finally if you appened a builtin install to INSTALLS <em>qmake</em> (and do not specify a files or extra member) will decide what needs to be copied for you, currently the only supported builtin is target:</p>
<pre>
  target.path = /usr/local/myprogram
  INSTALLS += target
</pre>
<p>With this <em>qmake</em> will know what you plan need copied, and do this for you.</p>
<a name="cache"></a><h4><a name="6-3"></a>Cache File</h4>
<p>The cache file (mentioned above in the options) is a special file <em>qmake</em> will read to find settings not specified in the <tt>qmake.conf</tt> file, the .pro file, or the command line. If <tt>-nocache</tt> is specified, <em>qmake</em> will try to find a file called <tt>.qmake.cache</tt> in parent directories. If it fails to find this file, it will silently ignore this step of processing.</p>
<a name="LibDepend"></a><h4><a name="6-4"></a>Library Dependencies</h4>
<p>Often when linking against a library <em>qmake</em> relies on the underlying platform to know what other libraries this library links against, and lets the platform pull them in. In many cases, however, this is not sufficent. For example when statically linking a library there are no libraries linked against, and therefore no dependencies to those libraries are created - however an application that later links against this library will need to know where to find the symbols that the linked in library will require. To help with this situation <em>qmake</em> will follow a library's dependencies when it feels appropriate, however this behaviour must be enabled in <em>qmake</em>. To enable requires two steps. First, you must enable it in the library - to do this you must tell <em>qmake</em> to save information about this library:</p>
<pre>
  CONFIG += create_prl
</pre>
<p>This is only relevant to the lib template, and will be ignored for all others. When this option is enabled <em>qmake</em> will create a file (called a .prl file) which will save some meta information about the library. This metafile is itself just a qmake project file, but with all internal variables. You are free to view this file, and if deleted <em>qmake</em> will know to recreate it when necesary (either when the .pro file is later read, or if a dependent library (described below) has changed). When installing this library (by using target in INSTALLS, above) <em>qmake</em> will automatically copy the .prl file to your install path.</p>
<p>The second step to enabling this processing is to turn on reading of the meta information created above:</p>
<pre>
  CONFIG += link_prl
</pre>
<p>When this is turned on <em>qmake</em> will process all libraries linked to, and find their meta information. With this meta information <em>qmake</em> will figure out what is relevant to linking, specifically it will add to your list of DEFINES as well as LIBS. Once <em>qmake</em> has processed this file, it will then look through the newly introduced LIBS and find their dependent .prl files, and continue until all libraries have been resolved. At this point the makefile is created as usual, and the libraries are linked explicity against your program.</p>
<p>The internals of the .prl file are left closed so they can easily change later. It is not designed to be changed by hand however, and should only be created by <em>qmake</em> - these .prl files should also not be transfered from operating system to operating system as they may be platform dependent (like a makefile).</p>
<a name="Extensions"></a><h4><a name="6-5"></a>File Extensions</h4>
<p>Under normal circumstances <em>qmake</em> will try to use appropriate file extensions for your platform. There may be times, however, that you would like to override the behavior of these extensions. To do this, you must modify builtin variables in your .pro file, which will in turn changes <em>qmake</em>'s interpretation of these files. You may do this as:</p>
<pre>
  QMAKE_EXT_MOC = .mymoc
</pre>
<p>The variables are as follows:</p>
<ul><li><p>QMAKE_EXT_MOC - This modifies the extension placed on included moc files.</p>
<li><p>QMAKE_EXT_UI - This modifies the extension used for designer UI files (usually in FORMS).</p>
<li><p>QMAKE_EXT_PRL - This modifies the extension placed on <a href="qmake-manual-7.html#LibDepend">library dependency files</a>.</p>
<li><p>QMAKE_EXT_LEX - This changes the suffix used in files (usually in LEXSOURCES).</p>
<li><p>QMAKE_EXT_YACC - This changes the suffix used in files (usually in YACCSOURCES).</p>
<li><p>QMAKE_EXT_OBJ - This changes the suffix used on generated object files.</p>
</ul><p>All the above accept just the first value, so you must assign to it one value that will be used through your makefile. There are two variables that accept a list of values, they are:</p>
<ul><li><p>QMAKE_EXT_CPP - Changes interpretation all files with these suffixes to be C++ source files.</p>
<li><p>QMAKE_EXT_H - Changes interpretation all files with these suffixes to be C header files.</p>
</ul><a name="Customizing"></a><h4><a name="6-6"></a>Customizing Makefile Output</h4>
<p>qmake often tries to be all things to all build tools, this is often less than ideal when you really need to run special platform dependent commands. This can be achieved with specific instructions to the different qmake backends (currently this is only supported by the UNIX <a href="qmake-manual-7.html#MAKEFILE_GENERATOR">generator</a>).</p>
<p>The interfaces to customizing the Makefile are done through "objects" as in other places in qmake. The notation for this is quite simple, first you fill in an "object" in qmake for example:</p>
<pre>
  mytarget.target = .buildfile
  mytarget.commands = touch $$mytarget.target
  mytarget.depends = mytarget2

  mytarget2.commands = @echo Building $$mytarget.target
</pre>
<p>The information above defines a qmake target called mytarget which contains a Makefile target called .buildfile, .buildfile is generated by 'touch .buildfile', and finally that this Makefile target depends on the qmake target mytarget2. Additionally we've defined the qmake target mytarget2 which simply echo's something to stdout.</p>
<p>The final step to making use of the above is to instruct qmake that this is actually an object used by the target building parts of qmake by:</p>
<pre>
QMAKE_EXTRA_UNIX_TARGETS += mytarget mytarget2
</pre>
<p>This is all you need to do to actually build custom targets in qmake,