# Source build

How a source tree becomes an installed shared library:
`configure`, the Makevars assembly, and the tarball round trip.

```sh
export MAKEFLAGS="-j$(nproc)"
R CMD INSTALL . --no-byte-compile
```

The first build compiles the whole vendored engine — tens of minutes;
an agent driving it must not cancel it.
An edit-test loop should not use this build at all:
[`fast-paths/`](/handbook/build/fast-paths/README.md)
turns the same command into seconds.

**Two stages.**
`R CMD INSTALL` runs `./configure` (`configure.win` on Windows),
then `make` in `src/` driven by `src/Makevars`.
`configure` computes no compiler flags;
it writes small include fragments that `src/Makevars` picks up —
`Makevars.rstrtmgr`, then either `Makevars.system-lib` for the fast path
or a `Makevars.duckdb` copied from `src/include/from-tar.mk`
when `DUCKDB_R_PREBUILT_ARCHIVE` names an archive that extracts,
and from `src/include/to-tar.mk` when it does not
(`to-tar-win.mk` on Windows).
It deletes a stale `Makevars.system-lib` first,
so a plain install can never silently stay on the fast path,
and it restores `src/duckdb/` from `src/duckdb.tar.xz` when it did —
which is how a tarball built by
`R CMD build` compiles again under `R CMD check`.

**`.dd` files in `src/` stay in version control.**
They are dependency-tracking files generated by the
`%.dd: %.d` rule in `src/include/deps.mk`,
regenerated by `make` and never hand-edited;
a large diff in one means an `#include` changed.

*To deepen: absorb the Windows differences and the
`configure` step order from the scripts; drain
[#2234](https://github.com/duckdb/duckdb-r/issues/2234)'s
build half.*
