Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Currently cannot support multiple languages or non-clike languages

Open
#3 1 comment 6 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
c, cpp, objective-c, rust, zig

Research direction

No files, tests, or implementation entry points are named. Start by reviewing the existing CPS specification and its treatment of language-specific components, then determine how the proposed languages structure would fit. Done means agreeing on a language-agnostic schema and its ABI and key-value semantics for current and future languages.

Written by the indexing model from the issue text.

Description

enhancement help wanted need discussion

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.

Dominant language
Python
Stars
191
Forks
13
PR merge metrics
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from cps-org/cps

All issues in cps-org/cps

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.