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

Interface manifests

Open
#18 4 comments 0 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
cmake, cpp

Research direction

The issue names no repository files, tests, or entry points. Start by reviewing CPS files alongside CMake’s HEADERS FILE_SET metadata; done would require an agreed CPS manifest design that maps headers, and possibly module interfaces, to CPS-defined libraries.

Written by the indexing model from the issue text.

Description

enhancement help wanted

This is not a required feature for a "1.0" release of CPS. But I could see this being one of a few "killer apps" that drive goodwill and adoption for CPS.

The use case I have in mind is a tool, possibly a feature of a build system, that can communicate to project maintainers about when library dependencies are missing or unneeded. This is analogous to tools like include-what-you-use, but targeting interproject dependencies.

Now, there are various pieces of functionality needed to implement a feature like that, but there is a missing bit of data that seems to be essential but missing. Specifically we need to be able to tell what dependency a #include maps to. I believe a sensible way to supply that information is for CPS files to contain a manifest (or multiple manifests in some cases) describing the interface for the library. That is, not just provide the install location of the headers but a list of the headers themselves.

Essentially, a link-what-you-include tool would need to be able to look at a #include <some/arbitrary/interface> and know what CPS-defined libraries provide some/arbitrary/interface. Then actual dependency declarations (like *LINK_LIBRARIES properties on CMake targets) can be inspected for errors.

CMake already models the required metadata via the new HEADERS FILE_SET feature. I would be looking for a CPS version of that information exported for end users.

As we gain more opinions about C++ modules, I expect that module interfaces would likewise be listed, though I expect some version of that information would be available via whatever module metadata files are developed. This problem is more essential to C++ modules workflows since there's immediately a need to map from import some_arbitrary_module; to actual files to parse.

Dominant language
Python
Stars
191
Forks
14
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.