Analyzing a CMake/Conan build directory throws IllegalArgumentException

[oliver]

I'm trying to run ORT on the build directory of a CMake project. Since this is a build directory, it is not under version control.

I'm running ORT like this: /tmp/ort1/bin/ort --stacktrace -P ort.analyzer.allowDynamicVersions=true --info analyze -f JSON -i /tmp/build/ -o /tmp/ort-results/ort-analyzer-4.

This results in an exception:

Exception in thread "main" java.lang.IllegalArgumentException: The VcsInfo(type=Git, url=, revision=, path=) of project 'Conan::conanfile.txt:' cannot be found in Repository(vcs=VcsInfo(type=, url=, revision=, path=), vcsProcessed=VcsInfo(type=, url=, revision=, path=), nestedRepositories={}, config=RepositoryConfiguration(analyzer=null, excludes=Excludes(paths=[], scopes=[]), resolutions=Resolutions(issues=[], ruleViolations=[], vulnerabilities=[]), curations=Curations(packages=[], licenseFindings=[]), packageConfigurations=[], licenseChoices=LicenseChoices(repositoryLicenseChoices=[], packageLicenseChoices=[]))).
        at org.ossreviewtoolkit.model.OrtResult.getFilePathRelativeToAnalyzerRoot(OrtResult.kt:278)
        at org.ossreviewtoolkit.model.OrtResult.getDefinitionFilePathRelativeToAnalyzerRoot(OrtResult.kt:264)
        at org.ossreviewtoolkit.model.config.Excludes.findPathExcludes(Excludes.kt:61)
        at org.ossreviewtoolkit.model.OrtResult$projects$2.invoke(OrtResult.kt:115)
        at org.ossreviewtoolkit.model.OrtResult$projects$2.invoke(OrtResult.kt:111)
        at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
        at org.ossreviewtoolkit.model.OrtResult.getProjects(OrtResult.kt:111)
        at org.ossreviewtoolkit.model.OrtResult.getProject(OrtResult.kt:379)
        at org.ossreviewtoolkit.model.OrtResult.isProject(OrtResult.kt:542)
        at org.ossreviewtoolkit.model.OrtResult.isExcluded(OrtResult.kt:302)
        at org.ossreviewtoolkit.model.OrtResult.getProjects(OrtResult.kt:410)
        at org.ossreviewtoolkit.model.OrtResult.getProjects$default(OrtResult.kt:408)
        at org.ossreviewtoolkit.cli.commands.AnalyzerCommand.run(AnalyzerCommand.kt:245)
        at com.github.ajalt.clikt.parsers.Parser.parse(Parser.kt:198)
        at com.github.ajalt.clikt.parsers.Parser.parse(Parser.kt:211)
        at com.github.ajalt.clikt.parsers.Parser.parse(Parser.kt:18)
        at com.github.ajalt.clikt.core.CliktCommand.parse(CliktCommand.kt:400)
        at com.github.ajalt.clikt.core.CliktCommand.parse$default(CliktCommand.kt:397)
        at com.github.ajalt.clikt.core.CliktCommand.main(CliktCommand.kt:415)
        at com.github.ajalt.clikt.core.CliktCommand.main(CliktCommand.kt:440)
        at org.ossreviewtoolkit.cli.OrtMainKt.main(OrtMain.kt:76)

I've read in some places (e.g. #4958 (comment)) that analyzing a non-VCS directory is not really supported, but that there is intention to make this a supported use case (or something like that?). Is there an issue to track this idea?

Btw. the reason why I'm running ORT on the build directory rather than on the source directory is that we don't have a conanfile.txt in our sources, since we use https://github.com/conan-io/cmake-conan instead. During build a conanfile.txt file is created in the build directory though, so I wanted to analyze that file instead.

[sschuberth]

I've read in some places (e.g. #4958 (comment)) that analyzing a non-VCS directory is not really supported, but that there is intention to make this a supported use case

I'm actually not so sure anymore about our intention here 😆

Is there an issue to track this idea?

I believe the idea is better tracked at #2896, and I just closed #4958 in favor of it.

Btw. the reason why I'm running ORT on the build directory rather than on the source directory is that we don't have a conanfile.txt in our sources, since we use https://github.com/conan-io/cmake-conan instead.

Sounds more like you'd want #2031 then? Or could we support all CMake projects by always leveraging cmake-conan programmatically and reusing our existing Conan analyzer for it?

[oliver]

I've read in some places (e.g. #4958 (comment)) that analyzing a non-VCS directory is not really supported, but that there is intention to make this a supported use case

I'm actually not so sure anymore about our intention here 😆

Eh, I guess intentions can change over time :-D

Is there an issue to track this idea?

I believe the idea is better tracked at #2896, and I just closed #4958 in favor of it.

Thanks, that makes it easier to navigate this!

Btw. the reason why I'm running ORT on the build directory rather than on the source directory is that we don't have a conanfile.txt in our sources, since we use https://github.com/conan-io/cmake-conan instead.

Sounds more like you'd want #2031 then?

Or could we support all CMake projects by always leveraging cmake-conan programmatically and reusing our existing Conan analyzer for it?

[Disclaimer: I'm not an expert on CMake or Conan.]

So, I think solving #2031 would be a much better solution than running just the Conan analyzer (at least for the C++ projects that I'm familiar with).

But: not all CMake projects use Conan; and even if they use Conan they might still install some dependencies through other ways (e.g. in my projects there are some dependencies which are still installed via APT/DPKG).

Also, not all CMake+Conan projects necessarily use the cmake-conan tool; they could also have a conanfile.py or conanfile.txt in their source tree instead.

Another point is that while CMake might provide the most complete list of dependencies, I think it does not provide details like license or homepage for each dependency. OTOH Conan does provide those details.

So maybe the most complete solution for CMake projects would be:

• (1) analyze CMake project files to find all dependencies (this could mean analyzing CMake commands like find_package() and pkg_check_modules() in some way – tools like it-depends already do this in some way)
• (2) use the Conan analyzer to get details (license, homepage etc.) of those dependencies that were installed via Conan
  • (a) for projects that use cmake-conan, the Conan analyzer needs to look at the generated conanfile.txt in build directory
  • (b) for projects that have a conanfile.txt committed to version control, the Conan analyzer needs to look at the source directory instead
• (3) for non-Conan dependencies maybe there is no way to get license info etc.; or those details must be fetched e.g. from APT, or from pkg-config, or from SPDX header comments in source files...

So an analyzer for CMake projects would be really useful, to get a more complete list of dependencies.

But even then it will be necessary that the Conan analyzer can analyze a build directory which is not under version control (for case 2a). For those cases, ORT could use the source checkout directory as --input-dir, and then a Conan-specific config option could be added to specify where the build directory (with the generated conanfile.txt file) is located.

What do you think?

[sschuberth]

But even then it will be necessary that the Conan analyzer can analyze a build directory which is not under version control (for case 2a).

TBH, I don't see this happening any time soon. This CMake/Conan mix seems to be a rather special case, and I'd prefer to focus on getting "vanilla" CMake support (#2031) done.

[sschuberth]

I've read in some places (e.g. #4958 (comment)) that analyzing a non-VCS directory is not really supported, but that there is intention to make this a supported use case (or something like that?). Is there an issue to track this idea?

Closing this in favor of #8803.