D 2014-02-25T18:18:26.423
L building
P c7d0008513cef88db0983a16dad6f8c0e649d9a5
U stephan
W 2740
<h1>Building libfossil</h1>

See also: [AmalgamationBuild]

libfossil's canonical build system is currently aimed at platforms hosting GNU Make 3.81 or newer (most relatively recent platforms have 3.81, though some name it 'gmake' instead of 'make').

<strong>Prerequisites:</strong> libfossil requires that <tt>zlib</tt>, both the library and headers, be installed at the system level (where they normally are).

The first step is to configure the build tree, which generates some configuration and makefiles:

<nowiki><pre>
$ ./configure
</pre></nowiki>

Pass it the <tt>--help</tt> option for the list of options, but none are normally needed.

To change the compiler, pass <tt>CC=compiler-name</tt> to the configuration script. It is currently known to build cleanly with gcc, clang, and tcc on x64 and i386 Linux. Note that the makefiles tweak the compiler flags for those particular compilers, and may need similar tweaks for other compilers  (see <tt>config.make.in</tt>). When using clang it might be useful to pass <tt>CC='clang -fno-color-diagnostics'</tt> to disable color output. Normally clang detects that automatically, but it mis-detects when compiling from xemacs and the color codes break xemacs' understanding of the output.

To build it:

<nowiki><pre>
$ make # or gmake
</pre></nowiki>

That will compile the library and [f-tools | a few sample/test/demo applications]. Be careful with them - some modify the repository (but never without being told to).

<h2>Running Tests</h2>

The majority of the library's functionality is either covered by unit tests or tested indirectly via unit tests. The remaining functionality (which cannot be easily tested without modifying the repo) is tested via [f-tools|various apps].

The most fundamental of the sanity tests is the aptly-named <tt>f-sanity</tt>, which can be used like this:

<nowiki><pre>
$ cd f-apps
$ make # or gmake
$ ./f-sanity
</pre></nowiki>

If that runs to completion, without triggering an exception, "the world is round."

On Unix-like systems it should be possible to build the script bindings and run those unit tests:

<nowiki><pre>
$ cd th1ish
$ make # or gmake
$ make unit # runs the unit tests
$ make vg # runs the unit tests through valgrind,
          # complaining if it finds problems.
          # Also collects memory stats to a CSV file.
</pre></nowiki>


<h2>System vs. Local sqlite3</h2>

Because libfossil uses bleeding-edge features of sqlite3 (namely recursive queries), it includes its own copy of sqlite3 amalgamation. Once those features are widely out and about in the wild, we can revert the build process to use a system-level sqlite3. As of 20140201, it requires sqlite3 3.8.3+.
Z b1ad78a605f772c9c8906f4c35f6492e