XRT Version extraction scheme does not work when building from tagged releases
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- cpp, git
- Domain
- build-system
Research direction
Start by reproducing the build from the tagged archive 202210.2.13.466.tar.gz and trace how version.json and version.h are generated. Done means the archive builds without the Git repository errors and both generated files report version 2.13.466 rather than 2.13.0.
Written by the indexing model from the issue text.
Description
For instance if you try to build XRT from a tagged release such as:
https://github.com/Xilinx/XRT/archive/refs/tags/202210.2.13.466.tar.gz
You will see errors when building, such as:
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
And the generated / included version.json and version.h will have the incorrect release number.
In this case, it will state "2.13.0" instead of "2.13.466".
- Dominant language
- C++
- Stars
- 686
- Forks
- 549
- Avg merge
- 2d 4h
- Merged PRs (30d)
- 70
Contributor guide
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.
More from Xilinx/XRT
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
-
Difficulty 4/5 3-5 days Newbie friendliness 70/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
Sensor initialization takes very long when `--initial-sim-time` is set to current UNIX timestamp Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
gazebosim/gz-sensors#662 · 1 comment ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
comp-datalake
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
ClickHouse/ClickHouse#121222 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
LadybirdBrowser/ladybird#12123 ·