The repository contains library source, documentation, code examples and
full unit test suite.
</p>
<p>
Use latest version tag if you want to automatically get new versions via
<codeclass="literal">svn update</code>. Use other tags if you want to switch to
new versions only explicitly (for example, using <codeclass="literal">svn switch</code>
command). Also please note that Subversion trunk contains the work-in-progress
version of the code; while this means that you can get new features and
bug fixes from trunk without waiting for a new release, this also means
that occasionally the code can be broken in some configurations.
</p>
</div>
</div>
<divclass="section">
<divclass="titlepage"><div><div><h3class="title">
<aname="manual.install.building"></a><aclass="link"href="install.html#manual.install.building"title="Building pugixml"> Building pugixml</a>
</h3></div></div></div>
<p>
pugixml is distributed in source form without any pre-built binaries; you
have to build them yourself.
</p>
<p>
The complete pugixml source consists of four files - two source files, <codeclass="filename">pugixml.cpp</code> and
<codeclass="filename">pugixpath.cpp</code>, and two header files, <codeclass="filename">pugixml.hpp</code> and <codeclass="filename">pugiconfig.hpp</code>. <codeclass="filename">pugixml.hpp</code> is
the primary header which you need to include in order to use pugixml classes/functions;
<codeclass="filename">pugiconfig.hpp</code> is a supplementary configuration file (see <aclass="xref"href="install.html#manual.install.building.config"title="Additional configuration options"> Additional configuration
options</a>).
The rest of this guide assumes that <codeclass="filename">pugixml.hpp</code> is either in the current directory
or in one of include directories of your projects, so that <codeclass="computeroutput"><spanclass="preprocessor">#include</span><spanclass="string">"pugixml.hpp"</span></code>
can find the header; however you can also use relative path (i.e. <codeclass="computeroutput"><spanclass="preprocessor">#include</span><spanclass="string">"../libs/pugixml/src/pugixml.hpp"</span></code>)
or include directory-relative path (i.e. <codeclass="computeroutput"><spanclass="preprocessor">#include</span>
You don't need to compile <codeclass="filename">pugixpath.cpp</code> unless you use XPath.
</p></td></tr>
</table></div>
<divclass="section">
<divclass="titlepage"><div><div><h4class="title">
<aname="manual.install.building.embed"></a><aclass="link"href="install.html#manual.install.building.embed"title="Building pugixml as a part of another static library/executable"> Building pugixml as
a part of another static library/executable</a>
</h4></div></div></div>
<p>
The easiest way to build pugixml is to compile two source files, <codeclass="filename">pugixml.cpp</code> and
<codeclass="filename">pugixpath.cpp</code>, along with the existing library/executable. This process
depends on the method of building your application; for example, if you're
If you're using Microsoft Visual Studio and the project has precompiled
headers turned on, you'll see the following error messages:
</p>
<preclass="programlisting">pugixpath.cpp(3477) : fatal error C1010: unexpected end of file while looking for precompiled header. Did you forget to add '#include "stdafx.h"' to your source?</pre>
<p>
The correct way to resolve this is to disable precompiled headers for <codeclass="filename">pugixml.cpp</code> and
<codeclass="filename">pugixpath.cpp</code>; you have to set "Create/Use Precompiled Header"
Precompiled Header) to "Not Using Precompiled Headers". You'll
have to do it for both <codeclass="filename">pugixml.cpp</code> and <codeclass="filename">pugixpath.cpp</code>, for all project configurations/platforms
(you can select Configuration "All Configurations" and Platform
<aname="manual.install.building.static"></a><aclass="link"href="install.html#manual.install.building.static"title="Building pugixml as a standalone static library"> Building pugixml as
a standalone static library</a>
</h4></div></div></div>
<p>
It's possible to compile pugixml as a standalone static library. This process
depends on the method of building your application; pugixml distribution
comes with project files for several popular IDEs/build systems. There
are project files for Apple XCode3, Code::Blocks, Codelite, Microsoft Visual
Studio 2005, 2008, 2010, and configuration scripts for CMake and premake4.
You're welcome to submit project files/build scripts for other software;
see <aclass="xref"href="../manual.html#manual.overview.feedback"title="Feedback"> Feedback</a>.
</p>
<p>
There are two projects for each version of Microsoft Visual Studio: one
for dynamically linked CRT, which has a name like <codeclass="filename">pugixml_vs2008.vcproj</code>,
and another one for statically linked CRT, which has a name like <codeclass="filename">pugixml_vs2008_static.vcproj</code>.
You should select the version that matches the CRT used in your application;
the default option for new projects created by Microsoft Visual Studio
is dynamically linked CRT, so unless you changed the defaults, you should
use the version with dynamic CRT (i.e. <codeclass="filename">pugixml_vs2008.vcproj</code> for Microsoft
Visual Studio 2008).
</p>
<p>
In addition to adding pugixml project to your workspace, you'll have to
make sure that your application links with pugixml library. If you're using
Microsoft Visual Studio 2005/2008, you can add a dependency from your application
project to pugixml one. If you're using Microsoft Visual Studio 2010, you'll
have to add a reference to your application project instead. For other
<aname="manual.install.building.shared"></a><aclass="link"href="install.html#manual.install.building.shared"title="Building pugixml as a standalone shared library"> Building pugixml as
a standalone shared library</a>
</h4></div></div></div>
<p>
It's possible to compile pugixml as a standalone shared library. The process
is usually similar to the static library approach; however, no preconfigured
projects/scripts are included into pugixml distribution, so you'll have
to do it yourself. Generally, if you're using GCC-based toolchain, the
process does not differ from building any other library as DLL (adding
-shared to compilation flags should suffice); if you're using MSVC-based
toolchain, you'll have to explicitly mark exported symbols with a declspec
attribute. You can do it by defining <codeclass="computeroutput"><spanclass="identifier">PUGIXML_API</span></code>
macro, i.e. via <codeclass="filename">pugiconfig.hpp</code>:
pugixml uses several defines to control the compilation process. There
are two ways to define them: either put the needed definitions to <codeclass="filename">pugiconfig.hpp</code> (it
has some examples that are commented out) or provide them via compiler
command-line. Define consistency is important, i.e. the definitions should
match in all source files that include <codeclass="filename">pugixml.hpp</code> (including pugixml sources)
throughout the application. Adding defines to <codeclass="filename">pugiconfig.hpp</code> lets you guarantee
this, unless your macro definition is wrapped in preprocessor <codeclass="computeroutput"><spanclass="preprocessor">#if</span></code>/<codeclass="computeroutput"><spanclass="preprocessor">#ifdef</span></code>
directive and this directive is not consistent. <codeclass="filename">pugiconfig.hpp</code> will never
contain anything but comments, which means that when upgrading to new version,
you can safely leave your modified version intact.
is used instead. For example, to specify fixed calling convention, you
can define <codeclass="computeroutput"><spanclass="identifier">PUGIXML_FUNCTION</span></code>
to i.e. <codeclass="computeroutput"><spanclass="identifier">__fastcall</span></code>. Another
example is DLL import/export attributes in MSVC (see <aclass="xref"href="install.html#manual.install.building.shared"title="Building pugixml as a standalone shared library"> Building pugixml as
