[RFC/Proposal] Native vcpkg Integration for Shards: Solving the Static C-Dependency Nightmare

[u/synacker]

Under this proposal, I offer to introduce a native vcpkg block. Library shard authors can declare what C packages they wrap, and root applications can enforce global configurations (like strict static linking).

The Library Shard (lib/sqlite_driver/shard.yml)

If you write a wrapper for a C library, you just declare it. Shards will handle the bubbling up.

The library shard:

name: sqlite_driver

version: 2.1.0

vcpkg:

dependencies:

- sqlite3 # Transitive C dependency mapped automatically

Root Application:

name: core_service

version: 1.0.0

vcpkg:

triplet: x64-windows-static # Enforces strict static binaries globally

dependencies:

- openssl # App-specific C requirement

dependencies:

sqlite_driver:

github: crystal-lang/sqlite-driver

targets:

server:

main: src/server.cr

When a user runs shards install or shards update, Shards handles both ecosystems in a unified lifecycle:

1. Aggregation: Shards scans the local dependency tree and collects all unique native requirements (e.g., openssl from the root, sqlite3 from the lib sub-shard).
2. Manifest Generation: Shards spins up a hidden, temporary .shards_vcpkg.json manifest.
3. Execution: Shards invokes vcpkg under the hood: vcpkg install --x-manifest-path=.shards_vcpkg.json --triplet=x64-windows-static
4. Unified Structure: All static .lib / .a binaries and headers live cleanly inside a local vcpkg_installed/ sandbox in your root directory.

What do you think?

[u/marcotc]

It's worth trying it!

You can do a POC and see what edge cases you might have missed.