Getting started

Supported toolchains

Verified this session

  • Windows, native MinGW-w64 gcc (tested via build-windows.ps1 / make, PowerShell as the shell).
  • Linux, gcc + GNU make (tested inside WSL2 Ubuntu with gcc 15.2.0).

Nothing in the build requires a specific development branch; main is built and tested directly. macOS is handled by the same Makefile logic (PLATFORM := macos branch) but was not exercised in this session — no macOS environment was available to test.

Dependencies

  • A C11-capable gcc and GNU make. No CMake is required for the baseline build (a CMake graph is a proposed target in LPV1-03, not implemented yet).
  • Nothing else. The build does not require npm, a JVM, Python, or a web bundler.

OpenSSL: not currently required

Earlier project material (a demo recording, an old README) says an OpenSSL install and DLL are needed. That is not true of the current main build: grep -r openssl src/ finds nothing — no source file includes an OpenSSL header or calls an OpenSSL function. The Makefile has a dormant USE_OPENSSL=1 flag that only adds -lssl -lcrypto to the link line; nothing in the tree currently uses those symbols, so leave it at its default (0) unless you are adding code that needs it. Local-auto credential generation uses Windows' own BCryptGenRandom (via -lbcrypt) and Credential Manager (-ladvapi32) instead.

Windows-specific link libraries (-lws2_32 -lbcrypt -ladvapi32) and Linux/macOS's -pthread are added automatically by the Makefile's platform detection — you do not pass them yourself.

Build — Windows PowerShell

From the repository root:

.\build-windows.ps1 -Target rebuild

This detects gcc, records a toolchain fingerprint in build/.toolchain (changing compiler/target invalidates stale objects automatically), and produces:

lib\libpolycall.a      static archive
lib\libpolycall.dll    shared library (built, not yet used by the CLI itself — see C library and ABI)
bin\polycall.exe       the operator CLI, statically linked against libpolycall.a
bin\math-provider.exe  the C provider example

build-windows.ps1 -Target help lists the other targets (debug, release, static, clean). Plain make (via a shell that has it, such as MSYS2's) works identically — build-windows.ps1 just locates a working make/gcc pair first.

Build — Linux

make all

produces the equivalent Linux outputs:

lib/libpolycall.a
lib/libpolycall.so
bin/polycall
bin/math-provider

Clean builds

make clean      # removes build/, keeps lib/ and bin/ outputs from a prior build
make rebuild     # clean + all, removes lib/bin outputs and objects first
make distclean   # removes all generated files

None of these remove source files, Polycallfile, or anything else you created — only paths under build/, lib/, and bin/. Changing compiler, target triple, or relevant flags is detected via build/.toolchain and triggers an automatic rebuild of stale objects rather than a silent mix of old and new artifacts.

Running the test suites

make test          # consumer, parser, and CLI process-level tests together
make test-cli       # CLI process-level tests only (spawns the real bin/polycall)
make test-parser    # Polycallfile parser fixtures only

test-cli builds bin/polycall first if needed, then launches it as a real child process for every registered command and inspects its stdout, stderr, and exit status independently — it is not a mock of the CLI.

What's next

Continue to Your first Python call to run the runtime, a Python provider, and a real invocation end to end.