Documentation
¶
Overview ¶
Package cpp provides a concrete Cataloger implementations for the C/C++ language ecosystem.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func NewConanCataloger ¶ added in v0.60.0
NewConanCataloger returns a new C/C++ conanfile.txt and conan.lock cataloger object.
func NewConanInfoCataloger ¶ added in v0.95.0
NewConanInfoCataloger returns a new C/C++ conaninfo.txt cataloger object.
func NewVcpkgManifestCataloger ¶ added in v1.47.0
func NewVcpkgManifestCataloger(opts CatalogerConfig) pkg.Cataloger
vcpkg (the Microsoft C/C++ package manager) has two modes (https://learn.microsoft.com/en-us/vcpkg/concepts/classic-mode):
- classic mode: `vcpkg install <pkg>` populates a central tree at $VCPKG_ROOT/installed/.
- manifest mode: a vcpkg.json declares dependencies; after a build the resolved tree appears under vcpkg_installed/ (a vcpkg/status DB + per-triplet dirs).
what is on disk depends on where in the lifecycle the scan happens:
- source checkout (the dir-scan case): vcpkg.json (+ vcpkg-configuration.json, overlay ports) are present. vcpkg_installed/ is a build artifact and is gitignored, so it is NOT present; exact transitive versions live in the registry, not the manifest.
- built artifact: vcpkg_installed/ holds the actually-installed truth.
NewVcpkgManifestCataloger covers ONLY the manifest (dir/source) case: it reads vcpkg.json and its declared dependencies and resolves each dependency's manifest from the vcpkg registry. resolving the registry needs a local registry clone or a network clone, which is opt-in via CatalogerConfig.VcpkgAllowGitClone (wired to --enrich).
it deliberately does NOT cover installed state: vcpkg_installed/ (vcpkg/status, per-package vcpkg.spdx.json, copyright, ABI info), the build triplet (a build-time choice recorded only under vcpkg_installed/), and classic-mode central installs.
why there is no installed-state (vcpkg/status) cataloger yet: vcpkg_installed/ tends to be a gitignored build artifact, so whether it survives into a scannable target is pattern-dependent. it is dropped by slim multi-stage runtime images (the documented best practice copies only the app binary / binary cache between stages) and by dev/base images (which bootstrap the tool, not packages); no canonical public image ships a populated vcpkg/status by default. it is retained mainly in single-stage builder / CI / "fat" app images. so a status-based cataloger has real but not universal payoff and is deferred until it is worth the maintenance.
Types ¶
type CatalogerConfig ¶ added in v1.47.0
type CatalogerConfig struct {
// VcpkgAllowGitClone enables cloning remote git registries to resolve vcpkg manifest dependencies (requires network access).
// app-config: cpp.vcpkg-allow-git-clone
VcpkgAllowGitClone bool `yaml:"vcpkg-allow-git-clone" json:"vcpkg-allow-git-clone" mapstructure:"vcpkg-allow-git-clone"`
}
func DefaultCatalogerConfig ¶ added in v1.47.0
func DefaultCatalogerConfig() CatalogerConfig
func (CatalogerConfig) WithVcpkgAllowGitClone ¶ added in v1.47.0
func (c CatalogerConfig) WithVcpkgAllowGitClone(input bool) CatalogerConfig