Version retrieval fails when used as submodule
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 3.3k
- Forks
- 808
- PR merge metrics
- No merged PRs in 30d
Description
When including Opus as a git submodule, tags don't seem to be part of the data fetched by git. Therefore the logic applied here
https://github.com/xiph/opus/blob/12a356e431d1b2d3531d3d73de330bf9ee9be48b/cmake/OpusPackageVersion.cmake#L10-L12
doesn't work out and retrieving the version will fail.
Why are tags used in that way anyway? Wouldn't it be easier if the version was simply specified in the CMakeLists.txt? Then it wouldn't be necessary to include a dedicated version file in the released source trees either 👀
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with cmake/OpusPackageVersion.cmake, especially the version logic at the linked lines, and compare it with the CMakeLists.txt version handling. Reproduce configuration from an Opus git submodule where tags are unavailable. Done means version retrieval succeeds in that setup while released source trees continue to report the correct version.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, cmake
- Domain
- build-system
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100