Package Managers Supported by Detect 6.4.0

Owned by Ray O'Meara (Unlicensed)
Aug 09, 2020
16 min read

Package managers

This page lists and describes supported package managers that are used with Synopsys Detect.
Synopsys Detect uses detectors to find and extract dependencies from all supported package managers.

Bazel support

As of the following Synopsys Detect versions: 

  • Synopsys Detect 5.2.0 and later provides limited support for Bazel projects.

  • Synopsys Detect 5.2.0 and later supports dependencies specified in maven_jar workspace rules. 

  • Synopsys Detect version 6.0.0 and later supports dependencies specified in maven_install workspace rules.

  • As of Synopsys Detect version 6.4.0, Synopsys Detect also supports dependencies specified in haskell_cabal_library workspace rules.

The Bazel tool attempts to run on your project if you provide a Bazel build target using the Bazel target property.
The Bazel tool also requires a bazel executable on $PATH.

Synopsys Detect tries to determine the workspace dependency rule (maven_jar or maven_install) from the WORKSPACE file; if it can't, you can specify which rule you use with the Bazel dependency type property.

Processing for the maven_install workspace rule

The Bazel tool runs a bazel cquery on the given target to produce output from which it can parse artifact details such as group, artifact, and version for dependencies.

Synopsys Detect's Bazel detector uses commands very similar to the following to discover maven_install dependencies.

$ bazel cquery --noimplicit_deps 'kind(j.*import, deps(//tests/integration:ArtifactExclusionsTest))' --output build 2>&1 | grep maven_coordinates tags = ["maven_coordinates=com.google.guava:guava:27.0-jre"], tags = ["maven_coordinates=org.hamcrest:hamcrest:2.1"], tags = ["maven_coordinates=org.hamcrest:hamcrest-core:2.1"], tags = ["maven_coordinates=com.google.guava:listenablefuture:9999.0-empty-to-avoid-conflict-with-guava"], tags = ["maven_coordinates=org.checkerframework:checker-qual:2.5.2"], tags = ["maven_coordinates=com.google.guava:failureaccess:1.0"], tags = ["maven_coordinates=com.google.errorprone:error_prone_annotations:2.2.0"], tags = ["maven_coordinates=com.google.code.findbugs:jsr305:3.0.2"],

Then, it parses the group/artifact/version details from the values of the maven_coordinates tags.

Processing for the maven_jar workspace rule

The Bazel tool runs a bazel query on the given target to get a list of jar dependencies. On each jar dependency, the Bazel tool runs another bazel query to get its artifact details: group, artifact, and version.

The following is an example using the equivalent commands that Synopsys Detect runs, but from the command line of how Synopsys Detect's Bazel detector currently identifies components.

  1. First, it gets a list of dependencies:

    $ bazel query 'filter("@.*:jar", deps(//:ProjectRunner))' INFO: Invocation ID: dfe8718d-b4db-4bd9-b9b9-57842cca3fb4 @org_apache_commons_commons_io//jar:jar @com_google_guava_guava//jar:jar Loading: 0 packages loaded

     

  2. Then, it gets details for each dependency. It prepends //external: to the dependency name for this command.

    $ bazel query 'kind(maven_jar, //external:org_apache_commons_commons_io)' --output xml INFO: Invocation ID: 0a320967-b2a8-4b36-ab47-e183bc4d4781 <?xml version="1.1" encoding="UTF-8" standalone="no"?> <query version="2"> <rule class="maven_jar" location="/root/home/steve/examples/java-tutorial/WORKSPACE:6:1" name="//external:org_apache_commons_commons_io"> <string name="name" value="org_apache_commons_commons_io"/> <string name="artifact" value="org.apache.commons:commons-io:1.3.2"/> </rule> </query> Loading: 0 packages loaded

     

  3. Finally, it parses the group/artifact/version details from the value of the string element using the name of the artifact.

Processing for the haskell_cabal_library workspace rule

Bazel 2.1.0 or later is required.

  1. Synopsys Detect's Bazel detector runs a bazel cquery on the given target to produce output from which it can extract artifact project and version for dependencies.
    The Bazel detector uses a command very similar to the following to discover haskell_cabal_library dependencies.

     

  2. It then uses Gson to parse the JSON output into a parse tree, and extracts the name and version from the corresponding rule attributes.

Examples

mvn_install rule example

The following example runs (provided you add your Black Duck connection details to the Synopsys Detect command line) the Bazel tool on the //tests/integration:ArtifactExclusionsTest target in the rules_jvm_external project and discover dependencies defined with the maven_install repository rule:

haskell_cabal_library rule example

The following example runs (provided you add your Black Duck connection details to the Synopsys Detect command line) the Bazel tool on the //cat_hs/lib/args:args target in the rules_haskell/examples project and discovers dependencies defined with the haskell_cabal_library repository rule:


Cargo support

Synopsys Detect runs the Cargo detector if it finds either of the following files in your project:

  • Cargo.toml

  • Cargo.lock

The Cargo detector parses the Cargo.lock file for information on your project's dependencies. If the detector discovers a Cargo.toml file but not a Cargo.lock file, it will prompt the user to generate a Cargo.lock by running cargo generate-lockfile and then run Detect again.

The Cargo detector extracts the project's name and version from the Cargo.toml file. If it does not find a Cargo.toml file, it will defer to values derived by git, from the project's directory, or defaults.

C/C++ (Clang) support

C/C++ (Clang) support is limited to Linux systems that support one of the following package manager commands: APK, DPKG, or RPM.

For C/C++ projects on Linux systems that meet these requirements, Synopsys Detect can derive dependency information using information read from a JSON Compilation Database (compile_commands.json file) and the Linux package manager.

The JSON compilation database must be generated by your project build before running Synopsys Detect. There are multiple C/C++ build tools that are capable of generating a JSON compilation database. For example, some versions of CMake generate a JSON compilation database when run with the following option:

  • DCMAKE_EXPORT_COMPILE_COMMANDS=ON

The Clang detector runs when it finds a compile_commands.json file in the project directory. If the compile_commands.json file resides in a sub-directory, adjust the detector search depth to enable Synopsys Detect to find it. If the compile_commands.json file resides in a normally excluded subdirectory (for example ./build), you can turn off the default detector search exclusions, or fine-tune the detector search directory exclusion patterns.

For each compile command in the compile_commands.json file, the Clang detector runs a version of the command that is modified to ensure that it does not overwrite build artifacts, and generate a list of dependency files used. This is performed by adding the -M and -MF compiler options. It then uses the Linux package manager to identify which installed package owns each dependency file. These packages are added as a component to the results.

Any dependency file that is not recognized by the Linux package manager and resides outside the source directory (the directory containing the compile_commands.json file) is written to the status.json file under unrecognizedPaths.CLANG.

Docker image support

On Linux and Mac, Synopsys Detect can invoke Docker Inspector to inspect Docker images. For simple use cases, add either --detect.docker.image={repo}:{tag} or --detect.docker.tar={path to a Docker saved tarfile} to the Synopsys Detect command line.

When passed a value for either detect.docker.image or detect.docker.tar, Synopsys Detect runs Docker Inspector on the given image; in other words, the target image, creating one code location. Synopsys Detect by default runs the Black Duck Signature Scanner on the image. This is actually the file system a container created from the image has at startup time; refer to Synopsys Detect's scan target for more details. This creates a second code location.

Passing Docker Inspector property values to Docker Inspector from Synopsys Detect

For more complex use cases, you may need to pass Docker Inspector property values to Docker Inspector using Synopsys Detect. To do this, construct the Synopsys Detect property name by prefixing the Docker Inspector property name with detect.docker.passthrough

For example, suppose you need to set Docker Inspector's service.timeout value (the length of time Docker Inspector waits for a response from the Image Inspector services that it uses) to 480000 milliseconds. You add the prefix to the Docker Inspector property name to derive the Synopsys Detect property name detect.docker.passthrough.service.timeout. Therefore, add --detect.docker.passthrough.service.timeout=480000 to the Synopsys Detect command line.

For example:


You can set any Docker Inspector property using this method. However, you usually should not override the values of the following Docker Inspector properties (which Synopsys Detect sets) because changing their values is likely to interfere with Synopsys Detect's ability to work with Docker Inspector:

  • output.path

  • output.include.squashedimage

  • output.include.containerfilesystem

  • upload.bdio

Synopsys Detect's scan target

When a Docker image is run; for example, using a docker run command, a container is created. That container has a file system; in other words, the container file system. The container file system at the instant the container is created; in other words, the initial container file system can be determined in advance from the image without running the image. Because the target image is not yet trusted, Docker Inspector does not run the image; that is, it does not create a container from the image, but it does construct the initial container file system, which is the file system a container has at the instant it is created.

When Synopsys Detect invokes both Docker Inspector because either detect.docker.image or detect.docker.tar is set, and the Black Duck Signature Scanner, as it does by default, the target of that Black Duck signature scan is the initial container file system constructed by Docker Inspector, packaged in a way to optimize results from Black Duck's matching algorithms. Rather than directly running the Black Duck Signature Scanner on the initial container file system, Synopsys Detect runs the Black Duck Signature Scanner on a new image; in other words, the squashed image, constructed using the initial container file system built by Docker Inspector. Packaging the initial container file system in a Docker image triggers matching algorithms within Black Duck that optimize match results for Linux file systems.

In earlier versions of Synopsys Detect / Docker Inspector, Synopsys Detect ran the Black Duck Signature Scanner directly on the target image. This approach had the disadvantage of potentially producing false positives under certain circumstances. For example, suppose your target image consists of multiple layers. If version 1 of a package is installed in layer 0, and then replaced with a newer version of that package in layer 1, both versions exist in the image, even though the initial container file system only includes version 2. A Black Duck signature scan of the target image shows both versions, even though version 1 has been effectively replaced with version 2. The current Synopsys Detect / Docker Inspector functionality avoids this potential for false positives.

Isolating application components

If you are interested in components from the application layers of your image, but not interested in components from the underlying platform layers, you can exclude components from platform layers from the results.

For example, if you build your application on ubuntu:latest (your Dockerfile starts with FROM ubuntu:latest), you can exclude components from the Ubuntu layer(s) so that the components generated by Synopsys Detect using Docker Inspector and the Black Duck Signature Scanner contain only components from your application layers.

First, find the layer ID of the platform's top layer. To do this task:

Run the docker inspect command on the base image; in our example this is ubuntu:latest. Find the last element in the RootFS.Layers array. This is the platform top layer ID. In the following example, this is sha256:b079b3fa8d1b4b30a71a6e81763ed3da1327abaf0680ed3ed9f00ad1d5de5e7c. Set the value of the Docker Inspector property docker.platform.top.layer.id to the platform top layer ID. For example:

In this mode, there may be some loss in match accuracy from the Black Duck Signature Scanner because, in this scenario, the Black Duck Signature Scanner may be deprived of some contextual information, such as the operating system files that enable it to determine the Linux distribution, and that that may negatively affect its ability to accurately identify components.

GoLang support

Synopsys Detect has the following detectors for GoLang:

  • Go Lock (GO_DEP) detector

  • Go Gradle (GO_GRADLE) detector

  • Go Mod Cli (GO_MOD) detector

  • Go Vendor (GO_VENDOR) detector

  • Go Vndr (GO_VNDR) detector

Go Lock (GO_DEP) detector

The Go Lock (GO_DEP) detector:

  • discovers dependencies of GoLang projects.

  • attempts to run on your project if a Gopkg.lock file is found in your source directory.

  • does not rely on external executables; for example, go, dep, and others.

  • parses Gopkg.lock for dependencies.

The Go Gradle (GO_GRADLE) detector

The Go Gradle (GO_GRADLE) detector:

  • discovers dependencies of go language (GoLang) projects.

  • attempts to run on your project if a gogradle.lock file is found in your source directory.

  • does not rely on external executables; for example, go, dep, and others.

  • parses gogradle.lock for dependencies.

The Go Mod Cli (GO_MOD) detector

The Go Mod Cli (GO_MOD) detector:

  • discovers dependencies of go language (GoLang) projects.

  • attempts to run on your project if a go.mod file is found in your source directory.

  • requires that the go executable is on the PATH.

  • runs go list -m and go mod graph, and parses the output of both to discover dependencies.

The Go Vendor (GO_VENDOR) detector

The Go Vendor (GO_VENDOR) detector:

  • discovers dependencies of go language (GoLang) projects.

  • attempts to run on your project if the file vendor/vendor.json is found in your source directory.

  • does not rely on external executables; for example, go, dep, and others.

  • parses vendor/vendor.json for dependencies.

The Go Vndr (GO_VNDR) detector

The Go Vndr (GO_VNDR) detector:

  • discovers dependencies of go language (GoLang) projects.

  • attempts to run on your project if the file vendor.conf is found in your source directory.

  • does not rely on external executables; for example, go, dep, and others.

  • parses vendor.conf for dependencies.

Gradle support

Synopsys Detect has two detectors for Gradle:

  • Gradle inspector detector

  • Gradle parse detector

Gradle inspector detector

The Gradle inspector detector discovers dependencies of Gradle projects.

The Gradle inspector detector attempts to run on your project if it finds a build.gradle file in the source directory (top level).

The Gradle inspector detector also requires either gradlew or gradle:

  1. Synopsys Detect looks for gradlew in the source directory (top level). You can override this by setting the Gradle path property. If not overridden and not found:

  2. Synopsys Detect looks for gradle on $PATH.

The Gradle inspector detector runs gradlew dependencies to get a list of the project's dependencies, and then parses the output.

It consumes the output of gradlew dependencies with the help of a Gradle script (init-detect.gradle), which it usually downloads automatically. The file init-detect.gradle has a dependency DependencyGatherer that comes from https://github.com/blackducksoftware/integration-gradle-inspector . Filtering (including/excluding projects and configurations) is performed by this Gradle/Groovy code on the output of the gradlew dependencies command.

Running the Gradle inspector with a proxy

Synopsys Detect will pass along supplied proxy host and proxy port properties to the Gradle daemon if applicable.

Erlang/Hex/Rebar support

The Rebar detector discovers dependencies of Erlang projects that use the Hex package manager.

  • The Rebar detector runs if Synopsys Detect finds a rebar.config file in your project. A rebar3 executable must be found on the PATH or must be provided.

  • The Rebar detector runs the rebar3 tree command and parses the output for dependency information.

Lerna support

The Lerna detector registers in the presence of a lerna.json file.

  • It will then execute a lerna command to retrieve all the packages defined in the project.

  • Each package has a location within the project structure.

  • It is expected to find a package.json and some type of lock file. Supported lockfile types are package-lock.json, npm-shrinkwrap.json, and yarn.lock.

  • If no lockfile is present in the package, it will be assumed that all the dependencies defined within the package's package.json file will be resolved in the lockfile at the root of the project. If no lockfile is present at the root of the project, Lerna extraction will fail.

Extracting from package-lock.json

The Lerna detect will execute the same code as the NPM package lock detector.

The NPM package lock detector related properties also apply.

Since the Lerna detector is currently not using the NPM Cli, only the detect.npm.include.dev.dependencies property applies.

Extracting from npm-shrinkwrap.json

The Lerna detect will execute the same code as the NPM shrinkwrap detector.

The NPM shrinkwrap detector related properties also apply.

Since the Lerna detector is currently not using the NPM Cli, only the detect.npm.include.dev.dependencies property applies.

Extracting from yarn.lock

The Lerna detect will execute the same code as the Yarn detector.

The Yarn detector related properties also apply.

Private packages

With the detect.lerna.include.private property, users can specify whether or not to include private packages as defined by Lerna.

Lerna path

Synopsys Detect executes commands against the Lerna executable to determine package information.

Synopsys Detect will attempt to find the Lerna executable, but if the user wishes to override the executable Detect uses, they can supply a path to the executable using detect.lerna.path

Maven support

Synopsys Detect has two detectors for Maven:

  • Maven Pom detector

  • Maven Parse detector

Maven Pom detector

The Maven Pom detector discovers dependencies of Maven projects.

The Maven Pom detector attempts to run on your project if it finds a pom.xml file in the source directory (top level).

The Maven Pom detector also requires either mvnw or mvn:

  1. Synopsys Detect looks for mvnw in the source directory (top level). You can override this by setting the Maven path property. If not overridden and not found:

  2. Synopsys Detect looks for mvn on $PATH.

The Maven Pom detector runs mvn dependency:tree to get a list of the project's dependencies and then parses the output.

Scope inclusion/exclusion is performed during the parsing of the output of the mvn dependency:tree command. When a component of an included scope is found under a component of an excluded scope, it is added to the BOM under a top-level placeholder component named Additional_Components.

npm support

Synopsys Detect has the following npm detectors:

  • npm package lock detector

  • npm package shrinkwrap detector

  • npm package JSON detector

  • npm CLI detector

npm package lock

The npm package lock is the preferred npm detector and runs when it finds a package-lock.json generated by npm.

npm automatically generates the package-lock.json after an npm install which should be run prior to scanning.

This is the most accurate way Synopsys Detect supports npm as the lock file contains resolved versions and all transitives.

npm shrinkwrap

The npm shrinkwrap detector uses the npm-shrinkwrap.json file.

It is the same as a package-lock.json but is a publishable lock file. Synopsys Detect always chooses shrinkwrap over package lock.

npm detector

The npm CLI detector requires a package.json and an npm executable.

It executes npm -ls json, and verifies that it succeeded by ensuring that no messages were written to stderr and that the exit code was 0. If both conditions are met, it parses the output for dependencies.

If npm -ls json does write messages to stderr (for example, lint messages) that you would like Synopsys Detect to ignore, you can silence errors by adding the --silent npm argument to the npm command using Synopsys Detect property --detect.npm.arguments.

This detector is only invoked if the other npm detectors are not invoked, and generating lock files for the other detectors should be preferred.

npm package JSON

The npm CLI detector is the fallback when in Build mode. When in buildless the fallback detector is npm package JSON.

This is the least accurate of the npm detectors.

It requires and parses a package.json file.

It does not find transitives and only reports the wild-card version present in the file.

NuGet support

The NuGet detectors can discover dependencies of NuGet projects.

Overview

There are two Nuget detectors: the NuGet solution detector, and the NuGet project detector. Each detector runs one of three available inspectors: the new DotNet 3.1 inspector, the DotNet inspector (for DotNet 2.1 runtime), or the old Classic inspector (aka exe inspector).

On non-Windows systems: The DotNet 3.1 and DotNet inspectors are supported. A DotNet executable is required.

On Windows systems: All inspectors (DotNet 3.1, DotNet, and Classic) are supported. A DotNet executable is not required. If no DotNet executable is found, Synopsys Detect runs the Classic inspector.

By default, Synopsys Detect looks for DotNet on $PATH. You can override this by setting the DotNet path property to point to your DotNet executable.

The NuGet detectors do not work with mono.

DotNet 3.1 inspector


Source: https://github.com/blackducksoftware/nuget-dotnet3-inspector

Binary: https://sig-repo.synopsys.com/bds-integrations-nuget-release/NugetDotnet3Inspector/

Runtime: DotNet 3.1

Requires: .NET framework version 4.5

DotNet inspector (dotnet)

Source: https://github.com/blackducksoftware/blackduck-nuget-inspector

Binary: https://sig-repo.synopsys.com/bds-integrations-nuget-release/BlackduckNugetInspector/

Requires: .NET framework version 4.5

Classic inspector

Source:

Binary: https://sig-repo.synopsys.com/bds-integrations-nuget-release/IntegrationNugetInspector/

Operation

Each inspector (DotNet 3.1, DotNet, and Classic) supports two detectors: NuGet solution detector, and NuGet project detector.

The NuGet solution detector derives packages (dependencies) from solution (.sln) files.

The Nuget project detector derives packages (dependencies) from project (.csproj, .fsproj, etc.) files. The supported project files are:

The NuGet solution detector runs if one or more solution (.sln) files are found.

The NuGet Project detector runs if no solution files are found, and one or more project files are found. Refer to the preceding list of project file types.

The NuGet detectors run the appropriate inspector (dotnet 3.1: NugetDotnet3Inspector, dotnet 2.1: BlackduckNugetInspector, or classic: IntegrationNugetInspector), which it normally downloads automatically.

The NuGet inspectors derive dependency information from the first type of file in this order:

  1. packages.config

  1. project.lock.json

  1. project.assets.json

  1. project.json

  1. XML of the project file

After discovering dependencies, the dotnet inspector (NugetDotnet3Inspector or BlackduckNugetInspector) and the classic inspector (IntegrationNugetInspector) use NuGet client libraries to collect further information about the dependencies and write it to a JSON file (<projectname>_inspection.json). Synopsys Detect then parses that file for the dependency information.

Python support

Synopsys Detect has the following detectors for Python:

  • Pip detector

  • Pipenv detector

  • Poetry detector

The Pip detector

The Pip detector discovers dependencies of Python projects.

The Pip detector attempts to run on your project if either a setup.py file is found, or a requirements.txt file is provided using the --detect.pip.requirements.path property.

The Pip detector also requires Python and pip executables:

  • Synopsys Detect looks for python (or python3 if the python3 property is set to true) on $PATH. You can override this by setting the python path property.

  • Synopsys Detect looks for pip (or pip3 if the python3 property is set to true) on $PATH.

The Pip detector runs the pip-inspector.py script, which uses Python/pip libraries to query the pip cache for the project, which may or may not be a virtual environment, for dependency information:

  1. pip-inspector.py queries for the project dependencies by project name which can be discovered using setup.py, or provided using the detect.pip.project.name property, using the pkg_resources library. If your project is installed into the pip cache, this discovers dependencies specified in setup.py.

  2. If a requirements.txt file is provided, pip-inspector.py uses the Python API called parse_requirements to query the requirements.txt file for possible additional dependencies and uses the pkg_resources library to query for the details of each. The parse_requirements API is unstable, leading to the decision to deprecate this detector.

Ramifications of this approach:

  • Because pip-inspector.py uses the pkg_resources library to discover dependencies, only those packages which have been installed; using, for example, pip install, into the pip cache; in other words, appearing in the output of pip list, are included in the output. There must be a match between the package version on which your project depends and the package version installed in the pip cache. Additional details are available in the pkg_resources library documentation.

  • If the packages are installed into a virtual environment for your project, you must run Synopsys Detect from within that virtual environment.

Recommendations:

  • Be sure that Synopsys Detect is finding the correct Python executable; this can be done by running the logging level at DEBUG and then reading the log. This is a particular concern if your system has multiple versions of Python installed; you must be sure Synopsys Detect is using the correct Python version.

  • Create a setup.py file for your project.

  • Install your project and dependencies into the pip cache:

  • The Pip detector derives your project name using your setup.py file if you have one. If you do not have a setup.py file, you must provide the correct project name using the property --detect.pip.project.name.

  • If there are any dependencies specified in requirements.txt that are not specified in setup.py, then provide the requirements.txt file using the Synopsys Detect property.

  • If you are using a virtual environment, be sure to switch to that virtual environment when you run Synopsys Detect. This also applies when you are using a tool such as Poetry that sets up a Python virtual environment.

Pipenv detector

The Pipenv detector discovers dependencies of Python projects.

The Pipenv detector attempts to run on your project if either of the following is true:

  1. A Pipfile is found.

  2. A Pipfile.lock file is found.

The Pipenv detector also requires Python and Pipenv executables:

  • Synopsys Detect looks for python (or python3 if the python3 property is set to true) on $PATH. You can override this by setting the python path property.

  • Synopsys Detect looks for pipenv on $PATH.

The Pipenv detector runs pipenv run pip freeze and pipenv graph --bare --json-tree and derives dependency information from the output. The dependency hierarchy is derived from the output of pipenv graph --bare --json-tree. The output of pipenv run pip freeze is used to improve the accuracy of dependency versions.

To troubleshoot of the Pipenv detector, start by running pipenv graph --bare --json-tree, and making sure that the output looks correct since this is the basis from which Synopsys Detect constructs the BDIO. If the output of pipenv graph --bare --json-tree does not look correct, make sure the packages (dependencies) are installed into the Pipenv virtual environment (pipenv install).

Poetry detector

The Poetry detector discovers dependencies of Python projects.

The Poetry detector attempts to run on your project if either of the following is true:

  1. A poetry.lock file is found.

  2. A pyproject.toml file is found.

The Poetry detector parses poetry.lock for dependency information. If the detector discovers a pyproject.toml file but not a poetry.lock file, it will prompt the user to generate a poetry.lock by running poetry install and then run Detect again.

The Poetry detector extracts the project's name and version from the pyproject.toml file. If it does not find a pyproject.toml file, it will defer to values derived by Git from the project's directory, or defaults.

Yarn support

Synopsys Detect runs the Yarn detector if it finds both of the following files in your project:

  • yarn.lock

  • package.json

The Yarn detector reads both files and derives project and dependency information from their contents.

Yarn Workspace Support

Synopsys Detect does not currently support Yarn workspaces as defined here.

Yocto (BitBake)

The BitBake detector discovers dependencies of custom Linux distribution projects built using Yocto versions 2.0 through 3.0.

The BitBake detector attempts to run on your project if all of the following are true:

  1. A build environment init script (typically oe-init-build-env) is found in the source directory.

  2. You provide at least one package name (target image name) using the BitBake package names property. Synopsys Detect will not run the Bitbake detector if this property is not set.

The BitBake detector attempts to source the oe-init-build-env file on your behalf.

The BitBake detector also requires a bash executable, which it looks for on $PATH. You can override this by setting the bash path property.

The BitBake detector does the following for each provided recipe name: The detector sources the build environment setup script and executes bitbake -g {package-name} to generate a dependency file recipe-depends.dot that it parses for dependency information. It also uses bitbake-layers show-recipes to gather layer information.

Troubleshooting Tips

Missing components for projects using the Yocto Package Revision Service

Symptom: Components are missing from the Black Duck BOM.

Problem: The Yocto Package Revision Service can increment a package revision to a value not present in the Black Duck KnowledgeBase, causing a package to fail to match.

©2018 Synopsys, Inc. All Rights Reserved