Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wesnoth: update to 1.14.9 #15174

Merged
merged 1 commit into from Oct 6, 2019
Merged

wesnoth: update to 1.14.9 #15174

merged 1 commit into from Oct 6, 2019

Conversation

obunden
Copy link
Contributor

@obunden obunden commented Oct 6, 2019

No description provided.

@obunden
Copy link
Contributor Author

obunden commented Oct 6, 2019

Seems like the compilation is spamming travis a bit too much. What would be the right way to go about fixing this? I tried passing different options to the configure_args but it doesn't affect the output. I thought the '-Wno-deprecated' option in cmake would get rid of the problem but there is a lot of warnings about old style casts still. Not sure how to see if the option is used or not, might it be the xbps cmake build script that overrides it?

I would be glad to get some input on how to solve this the right way.

@Hoshpak
Copy link
Member

Hoshpak commented Oct 6, 2019

I wouldn't bother with it at all. There are many packages that don't pass travis because they take too long to compile or produce too much output. Passing travis is an indicator that the build works, not a strict requirement for a PR to be merged.

The build should be tested manually for the relevant architectures in this case. If you don't have the time or hardware resources to do it, I could run some builds later.

@obunden
Copy link
Contributor Author

obunden commented Oct 6, 2019

The hardware is probably the biggest problem. I don't have musl installed anywhere right now but that could probably be arranged. But even then I only have access to x86/x86_64. So if you/someone else could test it on the other platforms that would surely help things. I'll post an update here when I tested everything that I can, but not sure when I will get the time.

@Hoshpak Hoshpak self-assigned this Oct 6, 2019
@Hoshpak
Copy link
Member

Hoshpak commented Oct 6, 2019

x86_64 is fine, it's the architecture the build servers are running. I don't have Void running on any other architecture either. xbps-src gives you everything you need to cross-compile to another architecture or have a separate masterdir for a compatible architecture.

To cross-compile, you just pass the target architecture with -a, like

./xbps-src -a armv6l pkg wesnoth

For a compatible architecture, just create a separate masterdir once and use that to compile, e.g.

./xbps-src -m musl binary-bootstrap x86_64-musl
./xbps-src -m musl pkg wesnoth

But I don't want to burden you too much, I'm currently running some builds for musl and several cross-compiled architectures and will merge if they pass.

@Hoshpak Hoshpak merged commit cb0e1cb into void-linux:master Oct 6, 2019
@obunden
Copy link
Contributor Author

obunden commented Oct 6, 2019

That's neat, good to know. Thanks once again for all the help. Hopefully I can be a bit more self-reliant if I manage to learn some more about all of this stuff.

@obunden obunden deleted the wesnoth branch October 22, 2019 02:35
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 4, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants