1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
-
+
-
-
-
+
+
+
|
# Hacker's Guide
See also: [](building), [](AmalgamationBuild)
This page primarily contains notes for anyone who's actively hacking on libfossil internals, e.g. changing <tt>fsl_cx</tt>'s structure.
This page primarily contains notes for anyone who's actively hacking on libfossil internals, e.g. changing `fsl_cx`'s structure.
An <em>exceedingly brief</em> intro to the source tree:
* The primary "exported" distributable is the [](AmalgamationBuild). The other sources and headers are essentially components for creating that deliverable.
* Public headers go in `include/fossil-scm/`. There is at least one pseudo-private header (`fossil-internal.h`) there as well, but that one is under consideration for being moved to...
* Private impl files and headers go in [src/](/dir/src).
* Demo/test apps can be found in [f-apps/])/dir/f-apps).
* The truly adventurous might want to explore the other various subdirs, like [sql/](/dir/sql) (schema files - these get compiled into the library as C code), [bindings/cpp/](/dir/bindings/cpp) (one of any number of potential C++ bindings) and [bindings/s2/](/dir/bindings/s2) (one of any number of potential script bindings).
* Private impl files and headers go in [src/](/dir/src?ci=trunk).
* Demo/test apps can be found in [f-apps/](/dir/f-apps?ci=trunk).
* The truly adventurous might want to explore the other various subdirs, like [sql/](/dir/sql?ci=trunk) (schema files - these get compiled into the library as C code), [bindings/cpp/](/dir/bindings/cpp?ci=trunk) (one of any number of potential C++ bindings) and [bindings/s2/](/dir/bindings/s2?ci=trunk) (one of any number of potential 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 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 _not_ picky about placement of spaces around parenthesis and whatnot, mainly just the overall 2-space indentation and `{` bracing `}` 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.
## Getting it Running Locally (on Unix-like systems)
Because of where the libs live vs where the binaries live, the easiest ways to get the source tree running its test apps are...
|