<h1>Hacker's Guide</h1>

This page primarily contains notes for anyone who's actively hacking on libfossil internals, e.g. changing <tt>fsl_cx</tt>'s structure.

An <em>exceedingly brief</em> intro to the source tree:

  *  Public headers go in <tt>include/fossil-scm/</tt>.
  *  Private impl files and headers go in <tt>src/</tt>.
  *  Demo/test apps can be found in <tt>f-apps/</tt>.
  *  The truly adventurous might wand to explore the other various subdirs, like <tt>cpp/</tt> (one potential C++ binding) and <tt>s2/</tt> (script bindings).
  *  The "native" build platform requires GNU Make 3.81 or higher and the conventional set of Unix-side build tools. Contributions of control files (or READMEs) for other build platforms are of course welcomed.
  *  The primary "exported" distributable is the [AmalgamationBuild]. The other sources and headers are essentially components for creating that deliverable.
  *  The overall style is a direct artifact (as it were) of fossil(1), and we ask that all contributors maintain the general overall style. We are <em>not</em> picky about placement of spaces around parenthesis and whatnot, mainly just the overall indentation and <tt>{</tt>bracing<tt>}</tt> styles, as well as the naming style for public symbols (e.g. a prefix of "fsl_" on most symbols). The one notable exception is how APIs are documented: libfossil uses Doxygen style (and Doxygen cannot swallow fossil's native comment style).



<h2>An Introduction to structs...</h2>

All (or almost all) structs in the library are accompanied by other constructs which help ensure (insure?) consistency regarding how library-level structs are to be initialized. The general pattern looks like this:

<nowiki><pre>
struct fsl_foo { ... };