Feature Request: add to shard support for manage C/C++ deps

Hi all,

The crystal lang provides good way for binding with C, but not provides way to manage a sets of C/C++ deps.

For example, I want to create a crystal lib for works with ffmpeg. The ffmpeg has a lot of deps. I can to bind with hope that system lib is exists, but there are next problems:

  1. Versions mismatch. I can write crystal lib based on ffmpeg 9, but the system has only ffmpeg 8
  2. No way to check that needed libs are exists (postscript don’t provide a way to do this perfectly)

From other side, the shard can manage also C/C++ deps with next limits:

  1. Only static build
  2. No binary storage, only a recipes for compilation
  3. The compilation flags cann’t change
  4. The compiler requirements cann’t change and auto d

My suggestion is add support to shard C/C++ deps in next way:

name: ffmpeg_crystal
version: 0.1.0
description: Crystal bindings for FFmpeg with self-compiling static dependencies.

# 1. Normal Crystal Shard dependencies
dependencies:
  kemal:
    github: kemalcr/kemal
    version: ~> 1.5.0

# 2. The New Proposed C/C++ Static Dependencies Block
native_dependencies:
  # Dependency name used as the linking identifier (e.g., -lopus)
  opus:
    git: https://github.com
    branch: master
    build_system: autotools
    # Immutable flags predefined by the shard author for static linking
    flags:
      - --enable-static
      - --disable-shared
      - --disable-extra-programs
      - --with-pic

  x264:
    git: https://videolan.org
    tag: stable
    build_system: makefile
    flags:
      - --enable-static
      - --enable-pic
      - --disable-cli

  # Target library depends on the upstream static libs
  libavcodec:
    git: https://github.com
    tag: n7.0
    build_system: autotools
    # Ensures opus and x264 are compiled and paths are mapped BEFORE building ffmpeg
    requires:
      - opus
      - x264
    flags:
      - --enable-static
      - --disable-shared
      - --enable-pic
      - --enable-libopus
      - --enable-libx264
      - --disable-programs
      - --disable-doc

What do you think about this proposal?

Or better way to reuse the vcpkg for c/c++ in shard like this:

name: core_service
version: 1.0.0

# 1. Global Native Orchestration Block
vcpkg:
  triplet: x64-windows-static   # Enforces strict static binaries globally
  dependencies:
    - openssl                    # Declared by the root project

dependencies:
  sqlite_driver:
    github: crystal-lang/sqlite-driver

targets:
  server:
    main: src/server.cr

name: sqlite_driver
version: 2.1.0

# 2. Local Library Declaration Block
vcpkg:
  dependencies:
    - sqlite3                    # Transitive C dependency

I also start discussion here: Reddit