Currently cannot support multiple languages or non-clike languages

[dcbaker]

I've been thinking about replacing pkg-config a lot, and one of the real short comings of pkg-config is that it assumes C (and C++ and ObjC kinda work because of that), but trying to use a newer language like Rust, Zig, or D is pretty painful, or just impossible. CPS kinda supports non-C languages through it's Type: "jar" mechanism, but that means each language has to be hard coded. It also means that you have to duplicate keys like c-runtime-vendor and cpp-runtime-vendor. I'd propose instead something like this:

{
  "platform": {
    "languages": {
      "c": {
        "runtime-vendor": "gnu",
      },
      "rust": {
        ...
       }
     }
  },
  "components": {
    "sample": {
      "language": "c",
      "type": "dylib",
      ...
     }
  }
}

This necessitates a couple of things: that the keys and their values in each component are language specific:" ie, rust doesn't provide a rust dynamic ABI, only a rust static lib ABI, but a component can be built with rust that provides a C ABI.

I think that solving the problems of future languages is really critical to making anything replacing pkg-config a success.

[SyseAdmine]

This package specification format could be indeed a gamechanger. Not only in the c-lang related world, but also for other languages and how they interop with each other. The specification should be usable for more if not all languages.