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


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
cd ~/packages/example-package
prokit build
# Verbose output
prokit build --verbosePackaging
prokit package
# Custom output directory
prokit package --output ~/packages/output/Inspecting
# Show package metadata
prokit info package-name.opk
# List package contents
prokit list package-name.opk
# Verify package integrity
prokit verify package-name.opkTypical Workflow
- Set up: Source the ProKit environment script
- Get source: Clone or create your source + metadata (control file, build rules)
- Configure: Pick your target architecture
- Build:
prokit build - Test: Try it on hardware or an emulator
- Package:
prokit package - 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:
- Follow the install guide
- Build the example packages to verify everything works
- Read the package format spec
- Modify an existing package to learn the build system
- 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.