Use upstream and allow system cxxtest #7056
No reviewers
Labels
No Label
Closed
Duplicate
Closed
Fixed
Closed
Invalid
Closed
Needs info
Closed
Won't fix
Closed
Works for me
Difficulty
Hard
Difficulty
Medium
Difficulty
Simple
Needed for Beta
Needs Design Input
Needs Info
Pathfinding
Priority
1: Release Blocker
Priority
2: Must Have
Priority
3: Should Have
Priority
4: Nice To Have
Priority
5: If Time Permits
Regression
Theme
AI
Theme
Art & Animation
Theme
Atlas editor
Theme
Build & Packages
Theme
Core engine
Theme
Documentation
Theme
Internationalization & Localization
Theme
Maps
Theme
Multiplayer Lobby
Theme
Music & Sound FX
Theme
Network
Theme
Non-game systems
Theme
Simulation
Theme
UI & Simulation
Theme
UI β Game setup
Theme
UI β In-game
Theme
UI β Miscellaneous
Theme
Website & Forum
Type
Defect
Type
Enhancement
Type
Task
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: 0ad/0ad#7056
Loadingβ¦
Reference in New Issue
Block a user
No description provided.
Delete Branch "sera/0ad:use-upstream-cxxtest"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This makes tests compatible with upstream cxxtest, replaces the custom version and allows system provided cxxtest to be used where available.
Closes: #5792
This is sort of a continuation of https://code.wildfiregames.com/D3119
One solution and probably the preferred one to get past the Linux build failure is to install the python-is-python3 package on the CI.
You could also patch it like the other libs since it's vendored.
For completeness, invoking as python3 cxxtestgen or installing cxxtest on the CI and using --with-system-cxxtest would work as well.
Still, in light that it's fair to assume python is python3 this days and given upstream never changed it, installing the package python-is-python3 on the CI gets my vote. I prefer to only backport upstream patches instead of diverging unless we really don't have an alternative.
I'm not sure but I think the CI now picks up docker changes?
Very nice patch and demonstration of the process for unbundling svn sources! π―
@ -31,6 +31,7 @@ RUN apt-get -qqy update && apt-get install -qqy --no-install-recommends \
make \
m4 \
patch \
python-is-python3 \
This package only exists in
bullseye
and later. I suggest you create manually a symlink later in the dockerfile.@ -5,2 +5,3 @@
LIB_VERSION=28209
PV=4.4
LIB_VERSION=${PV}
What's the rationale behind having both env vars?
LIB_VERSION could be changed to LIB_VERSION=${PV}+wfg1 when adding a patch later without upstream version bump, maybe should have that suffix always and start with wfg0 as for demonstration purpose.
@ -16,3 +18,2 @@
# unpack
rm -Rf cxxtest-4.4-build
cp -R cxxtest-4.4-svn cxxtest-4.4-build
rm -Rf cxxtest-4.4
Shouldn't you use the envvar for the directory name here?
good catch
@ -23,3 +25,3 @@
# install
rm -Rf bin cxxtest python
cp -R cxxtest-4.4-build/bin cxxtest-4.4-build/cxxtest cxxtest-4.4-build/python .
cp -R cxxtest-4.4/bin cxxtest-4.4/cxxtest cxxtest-4.4/python .
and here?
c3b085e32d
toaa0ad39fb5
@ -7,3 +8,2 @@
if [ -e .already-built ] && [ "$(cat .already-built)" = "${LIB_VERSION}" ]; then
echo "cxxtest-4.4 is already up to date."
if [ -e .already-built ] && [ "$(cat .already-built || true)" = "${LIB_VERSION}" ]; then
Don't forget this.
I don't see anything wrong with this line.
The .already-built shenanigans are the sole reason for ${LIB_VERSION}
|| true always true ?
This only suppress the return value of cat, not what it writes to stdout. This is needed because of posix shell, set -e and ultimately shellcheck, because it insist that the cat command may fail.
from the man page:
true - do nothing, successfully
https://www.shellcheck.net/wiki/SC2312
aa0ad39fb5
to5c981da29e
I think fixes of includes might be done in a separate patch.
It's a separate patch/commit and I intend to leave it as such, or do you mean separate pr instead?
Yeah, I meant a separate PR.
@Itms , the pipeline update doesn't seem reliable. Works on first attempted but when it's already in cache it seems to not load the right image somehow. Do you want to cherry-pick the Dockerfile update patch and if needed manually clear cache?
I was very puzzled as nothing seemed to indicate why Docker wouldn't use the correct buster-base image. The only hypothesis I can offer is that the pipeline might have run in parallel with another PR and that the "Setup" stage for another run happened between the "Setup" and "Linux Build" of the build #4. Wanting to test that hypothesis, I restarted a run, this time I could see that nothing was run between the steps, and it worked. π€·ββοΈ
5c981da29e
to33d734c717
33d734c717
to6f6ed63b11
Replaces /usr/bin/cxxtestgen with a search in PATH
@ -1404,1 +1405,3 @@
cxxtest.setpath(rootdir.."/libraries/source/cxxtest-4.4/bin/cxxtestgen")
if _OPTIONS["with-system-cxxtest"] then
local handle = io.popen("command -v cxxtestgen")
local cxxtestgen = handle:read("*a"):gsub("\n", " ")
Does this work if you have multiple installs?
We also just assume that the headers/sources are in system includes, so this gives the user more freedom to make things work, arguably this is now more correct, in practice I don't expect this to make a difference. Sure It's not impossible to artificially construct a case where things can go wrong, hardcoding the path doesn't make that any harder tho.
I meant can
command -v cxxtestgen
returnYou mean if a single invocation can return multiple results? Then no, the \n needs stripping so that the block behaves sort of like the shell command substitution.
Okay. Would have been kinda annoying for it to call two programs.
Checkout
From your project repository, check out a new branch and test the changes.