ProKit

The ProteanOS Development Kit for building, packaging, and managing embedded software.

Digital Ocean free trial – Cloud VPS Solutions
ProKit development workflow diagram

What is ProKit?

ProKit is the ProteanOS build and packaging toolkit. It handles cross-compilation setup, package building, dependency resolution, and output validation in a way that is consistent across packages and target architectures. The goal is that building any source package should work the same way regardless of what the upstream software uses internally.

If you have maintained cross-compilation setups manually, you know the pattern: environment variables in the wrong order, sysroot paths that differ between packages, autoconf scripts that detect the host instead of the target. ProKit sets up that environment consistently so packages built against the same target configuration produce compatible binaries.

What ProKit includes

ProKit includes:

  • Build driver: Runs the compiler with the right flags for your target
  • Package tools: Creates and manages packages per the Source Package Format
  • Environment setup: Scripts for switching between different target configs
  • Dependency resolver: Figures out what order to build things in
  • Quality checks: Validates packages against format requirements

Basic Commands

Most common operations:

Building

Build a package
cd ~/packages/example-package
prokit build

# Verbose output
prokit build --verbose

Packaging

Create a package
prokit package

# Custom output directory
prokit package --output ~/packages/output/

Inspecting

Package inspection commands
# Show package metadata
prokit info package-name.opk

# List package contents
prokit list package-name.opk

# Verify package integrity
prokit verify package-name.opk

Typical Workflow

  1. Set up: Source the ProKit environment script
  2. Get source: Clone or create your source + metadata (control file, build rules)
  3. Configure: Pick your target architecture
  4. Build: prokit build
  5. Test: Try it on hardware or an emulator
  6. Package: prokit package
  7. Share: Send patches for review

Configuration

Customize ProKit via:

  • ~/.config/prokit/config - Your personal settings
  • ./prokit.conf - Per-project settings
  • Environment variables: PROKIT_TARGET, PROKIT_SYSROOT, etc.

Getting Started

New to ProKit? Do this:

  1. Follow the install guide
  2. Build the example packages to verify everything works
  3. Read the package format spec
  4. Modify an existing package to learn the build system
  5. Package something new

Contributing

ProKit improvements and new packages are both welcome. For packages, follow SPF 2.0, test on at least one supported platform, and send patches to proteanos-dev using git format-patch. Include a description of what the package does and any non-obvious choices in the build rules.

For ProKit core changes, describe the problem the patch solves rather than just what it changes. If the patch affects existing package builds, test a representative cross-section before submitting.

ProKit FAQ

What is the difference between ProKit and a regular compiler toolchain?

A compiler toolchain gives you a cross-compiler and a sysroot. ProKit wraps that with package build conventions, dependency resolution, and output validation. The toolchain handles compilation; ProKit handles the full packaging workflow including control file processing, patch application, staging directory management, and OPK generation. You need both.

Can I use ProKit for native (non-cross) compilation?

Yes. Specifying a native target in the environment configuration builds for the host architecture. This is useful for testing packages on your development machine before testing on hardware, though native builds obviously will not catch architecture-specific issues.

How do I add support for a new target architecture?

Adding a new architecture requires configuring the toolchain settings for that target and ensuring the sysroot is populated with the correct base packages. The porting guide covers the hardware side of this. For the ProKit configuration, you need to define the correct CROSS_COMPILE prefix, compiler flags, and sysroot path for the new target.

Where are build artifacts stored?

Build outputs go into a build/ subdirectory within the package source tree by default. The staging directory (where installed files accumulate before packaging) and the output OPK file are both placed there. You can override the output path with --output if you need packages to land in a specific directory.

How do I debug build failures?

Run prokit build --verbose to see the full compiler and linker commands. The most useful diagnostic is usually the first error in the output, not the last - make often continues running and generates a cascade of secondary errors. Missing dependencies and incorrect sysroot configuration are the two most common causes. Check that all Build-Depends are installed in the sysroot for the target architecture.