Guidance for C/C++ projects for 'external_dependencies'

[jmertic]

C/C++ does not have a consensus package manager like other languages such as Python and Rust. Additionally, many projects tend to use CMake being used for builds, where FetchContent is often used for grabbing external dependencies.

What should be the guidance given for C/C++ projects? I tend to advise projects that 'if dependabot supports it, you should be fine', but even dependabot doesn't have support or consistency ( see dependabot/dependabot-core#2027 )

Any guidance would be most helpful - thanks!

[david-a-wheeler]

The text of external_dependencies says:

Externally-maintained components
The project MUST list external dependencies in a computer-processable way.

Details:
Typically this is done using the conventions of package manager and/or build system. Note that this helps implement installation_development_quick.

Often system-level package managers are used for C/C++ projects, which already deal with external dependencies and are machine-readable. I personally suggest using for rpm or deb (dpkg/apt/apt-get). Many build systems have approaches for doing it (as you noted) that are specific to them. That's why it only says "computer-processable" way; in C and C++ there's no widespread agreement on how to do it :-(. That said, if you record it somehow, then you can translate it.

[jmertic]

Got it - thanks! Could we add what you said to the details?

[david-a-wheeler]

We could. I would want to back off its one a little bit, e.g., instead of a "recommendation", because there are (obviously) big disagreements on how to do this. I wish there was some kind of agreement.

What about adding this to the details?

In ecosystems where there is a widely-accepted way to list external dependencies, you should use it. In cases where there is not (e.g., C and C++), consider using a build system mechanism (e.g., CMake FetchContent) or a system-level package format specification (such as an rpm spec file or Debian control file).

[jmertic]

I like it! @lgritz and @fpsunflower - do you think this would answer the questions you had?

[lgritz]

Clarification, please:

I had been previously imagining that the requirement was for more of an SBOM-like explicit list of dependencies in a standardized format, or perhaps like a Python requirements.txt.

If you say "using a build system mechanism (e.g., CMake FetchContent)", then are you implying that any programmatic way (like, within the cmake build scripts) that ensures you have the right set of dependencies at build time is sufficient?

While I have you and since cmake has been mentioned, there's also a requirement "MUST provide a way to easily install and uninstall the software produced by the project using a commonly-used convention." A common question we get from our C++ projects is that cmake doesn't provide a mechanism for making an "uninstall" target, so we often wonder what we're expected to do here. Does this requirement only apply if what we're providing is a binary installer (then we should also be able to uninstall), but perhaps not if we are a build-from-source project only, with packaging responsibilities delegated downstream?

[lgritz]

When we discussed this all yesterday, one piece of feedback we had is that for quite a few of the items, it would be great if there was a "per-paradigm" explanation of what compliance would entail -- what would constitute success if your project implements a web service, versus a user-facing desktop application, versus a C++ library, versus a Python module.