📄 xmake_documentation.html
字号:
<p>Besides the above attributes, the configuration also has the
following sub tags:</p>
<ul>
<li><code>includes</code> - The includes section informs <code> xmake</code> of
where to look for include files not in the current directory. This
is used during the dependency scan for source files.
<li><code>tools</code> - The tools sections allows you to specify
special build tools for build source files that are not able to be
compiled using the <code><samp>compiler</samp></code> and <code>linker</code>
in the configuration.
<li><code>compiler</code> - This specifies the compiler used to
compile source files (unless the source file specifies another <code>tool</code>).
<li><code>linker</code> - This specifies the linker used to
create the final project binary.
<li><code>preBuild</code> - not implemented yet.
<li><code>postBuild</code> - not implemented yet.</li>
</ul>
<p> </p>
<h4><code><includes></code></h4>
<p>This allows you to specify a set of directories to look in when
resolving dependencies for what to build. Each include directory
requires an include tag. Each include tag has a single attribute:</p>
<ul>
<li><code>path</code> - Where path is a directory path that will get
added to the list of directory paths to search for when determining
dependencies.</li>
</ul>
<p>An example looks something like this:</p>
<pre><includes>
<include path="../../MyDir/includes"/>
</includes>
.... more stuff follows</pre>
<p>By default the directory where the source file lives is search in the
dependency check.</p>
<p> </p>
<h4><code><tools></code></h4>
<p> The tools tag allows you to specify 0 or more tools that can be
used to build a specific type of file. The association of tool to a
source file is done with a source's "tool" attribute
having the same value as the tool's "id" attribute. Each tool
is described in a <tool> tag with the following attributes:</p>
<ul>
<li><code>name</code> - the name of the tool executable, such as
"rc.exe". You can specify a full or relative path.</li>
<li><code>id</code> - the text name of the tool. This is the name that
the various source entries will refer to the tool as. It can be
anything you want, so long as you consistently refer to it.</li>
</ul>
<p>Each tool tag can have flags associated with it. This is done by
using the <flags> tag to indicate the collection, and then a
<flag> sub tag. Each flag has the following attributes:</p>
<ul>
<li>value - the text parameters you want to pass to the tool</li>
</ul>
<p>The flags are then appended to on another to create a command line
that is then sent to the tool when needed. </p>
<p>An example looks something like this:</p>
<pre><tools>
<tool name="rc.exe" id="rc" > <!-- here we are using just the resource compilers file name,
assuming it can be found on the system path -->
<flags>
<flag value="/i'..\..\MyResIncludes' \d '_DEBUG'"/>
</flags>
</tool>
</tools>
.... more stuff follows</pre>
<p> </p>
<h4><code><compiler></code></h4>
<p>The compiler tag allows you to specify the executable to use as your
compiler (for a given configuration) and a set of flags to send to the
compiler when processing source files. The compiler tag has only a
single attribute:</p>
<ul>
<li>name - the relative or full path name to the executable to use for
compiling source files. If the name is just the short name (i.e.
"cl.exe"), then it is assumed that it can be found on the
system path.</li>
</ul>
<p>The compiler can have flags associated with it. This is done by
using the <flags> tag to indicate the collection, and then a
<flag> sub tag. Each flag has the following attributes:</p>
<ul>
<li>value - the text parameters you want to pass to the compiler</li>
</ul>
<p>The flags are then appended to on another to create a command line
that is sent to the compiler when it is invoked for each source file.</p>
<p>An example looks something like this:</p>
<pre><compiler name="cl">
<flags>
<flag value="/I $(INC)"/>
<flag value="/nologo /MDd /W3 /Gm /GR /GX /ZI /Od"/>
<flag value="/D WIN32 /D _DEBUG /D _CONSOLE /D _MBCS /D FRAMEWORK_DLL /D FRAMEWORK_EXPORTS"/>
<flag value="/c"/>
</flags>
</compiler >
.... more stuff follows</pre>
<p>Note the use of the variable <code>INC</code> in the first flag. Also
note that you could have just as easily put everything in one flag, but
breaking it up makes it easier to read for others.</p>
<p>Please note: Use single quote's where you would use double quotes.
Single quote characters will be expanded to double quote when the string is parsed and prepared to send to the compiler. </p>
<p> </p>
<h4><code><linker></code></h4>
<p>The linker tag allows you to specify the executable to use as your
linker (for a given configuration) and a set of flags to send to the
linker when linking all the compiler object code. The linker tag
has only a single attribute:</p>
<ul>
<li>name - the relative or full path name to the executable to use for
linking object files. If the name is just the short name (i.e.
"link.exe"), then it is assumed that it can be found on
the system path.</li>
</ul>
<p>The linker can have flags associated with it. This is done by
using the <flags> tag to indicate the collection, and then a
<flag> sub tag. Each flag has the following attributes:</p>
<ul>
<li>value - the text parameters you want to pass to the linker </li>
</ul>
<p>The flags are then appended to on another to create a command line
that is sent to the linker when it is invoked to build the final binary
image for the project.</p>
<p>An example looks something like this:</p>
<pre><linker name="link.exe">
<flags>
<flag value="/nologo"/>
<flag value="/subsystem:console"/>
<flag value="/incremental:yes"/>
<flag value="/pdb:'Debug/xmake.pdb'"/>
<flag value="/debug"/>
<flag value="/machine:I386"/>
<flag value="/out:'Debug/xmake.exe'"/>
<flag value="/pdbtype:sept"/>
</flags>
</linker>
.... more stuff follows</pre>
<p>Please note: Use single quote's where you would use double quotes.
Single quote characters will be expanded to double quote when the string is parsed and prepared to send to the
linker . </p>
<p> </p>
<h4><code><preBuild></code></h4>
<p>Currently this is not implemented yet. When it is, it will allow you
to specify a series of command line actions to execute <b><i>prior</i></b>
to the compile phase of the build process. preBuild is part of the
configuration tag and is thus associated with a specific
configuration. </p>
<p>The proposed syntax will probably look something like this:</p>
<pre><prebuild>
<exec commandLine="copy Foo.cpp ../../outputSrc"/>
<!-- ...other commands -->
</prebuild>
.... more stuff follows</pre>
<p> </p>
<h4><code><postBuild></code></h4>
<p>Currently this is not implemented yet. When it is, it will allow you
to specify a series of command line actions to execute <b><i>after</i></b>
the link phase of the build process. postBuild is part of the
configuration tag and is thus associated with a specific
configuration. </p>
<p>The proposed syntax will probably look something like this:</p>
<pre><postbuild>
<!-- in this example we use doxygen to autogenerate
source documentation-->
<exec commandLine="doxygen ../../help/Doxyfile"/>
<!-- ...other commands -->
</postbuild>
.... more stuff follows</pre>
<p> </p>
<h4><code><sources></code></h4>
<p>After the configurations are all specified you list you source files
that are required to build your project. The sources tag is a collection
of 1 or more source sub tags, with each source sub tag representing an
individual source file to build. The source tag has the following
attributes:</p>
<ul>
<li><code>name</code> - this is the name of the source file, relative
to the directory where the project is being built. This attribute is
required.</li>
<li><code>partOfConfig</code> - this indicates which
configuration the source file will compile under. The name of the
configuration <b><i>must</i></b> exactly match the name of the
configuration specified in one of the config sections that was
defined earlier in the makefile. If the source file can be compiled
under multiple configurations, then each configuration name must be
separated by the "|" character. This attribute is
required. </li>
<li><code>build</code> - indicates whether the file should even
be built for this configuration. The possible values for this
attribute are "yes" or "no". This attribute is
optional. If you do not specify this then it defaults to
"yes", meaning the file will be compiled.</li>
<li><code>outputAs</code> - this tells <code>xmake</code> where
the compiled object file should go. This will override the settings
in the compiler flags. Generally you want the two to match. By
specifying this <code>xmake</code> knows where to go to clean up the
object files during a "clean". This attribute is optional.
If you do not specify this then it defaults to the directory where
the project's makefile is. When specifying the name of the output
file you can leave off the extension (like foo.o or baz.obj) and
xmake will determine the proper extension from the configuration's <code>srcBinaryExt</code>
attribute. </li>
<li><code>tool</code> - tells <code>xmake</code> that the source file
is not compiled using the default compiler, instead it is to be
"compiled" using the tool whose <code>id</code> attribute
matches this attribute's value. The two values must match exactly.
If a tool does not exist in the makefile with a matching <code>id</code>
attribute then the source file is not compiled. This attribute is
required. </li>
</ul>
<p>An example looks something like this:</p>
<pre><sources>
<source name="Test1Make.rc" partOfConfig="VC++ Debug" outputAs="Debug/Test1Make.res" tool="rc"/>
<source name="StdAfx.cpp" partOfConfig="VC++ Debug" />
<source name="MainFrm.cpp" partOfConfig="VC++ Debug" outputAs="Debug/MainFrm.obj"/>
<source name="ChildView.cpp" partOfConfig="VC++ Debug" outputAs="Debug/ChildView.obj"/>
<source name="Test1Make.cpp" partOfConfig="VC++ Debug" outputAs="Debug/Test1Make.obj"/>
</sources></pre>
<p>Note the use of the tool attribute in the first source tag.</p>
<p> </p>
<h3>Building and installing <code>xmake</code></h3>
<p>You can get <code>xmake</code> from <a href="http://sourceforge.net/projects/vcf">here</a>
at the Source Forge VCF project page. You can build for Win32 systems
using the VC++ workspace that is included. Alternately it can be built
using GCC on 'nix systems using the traditional <code>configure</code>, <code>make</code>,
<code>make install</code> commands (a configure and Makefile are
provided for this). </p>
<p>It has been built and tested on Windows 2000, Windows NT sp4 (it is a
fairly simple command line tool so it should work fine in Windows 98 and
Windows XP), linux 2.4 (RH7.1 distro), SparcStation with Solaris 8
(2.8), and I have heard it runs on MacOSX and VMS but I have not
personally verified this. </p>
<p>To install it under Win32 systems just put the executable where you
want, preferably someplace that is on your system path. For 'nix systems
the <code>make install</code> command will put it in <code>/usr/bin</code>,
or you can place it somewhere else if you want.</p>
<p> </p>
<!------------------------------- That's it! --------------------------->
<p> </p>
</body>
</html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -