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

BUILD: Appveyor integration for Windows builds. #129

Closed
wants to merge 1 commit into from

Conversation

berenm
Copy link
Contributor

@berenm berenm commented Oct 13, 2016

@DrMcCoy
Copy link
Member

DrMcCoy commented Oct 13, 2016

Neat, thanks! :)

Now, what exactly do I have to do (besides merging that PR) to set up AppVeyor for xoreos?

@berenm
Copy link
Contributor Author

berenm commented Oct 13, 2016

I think it's more or less like for Travis-CI. You have to register to Appveyor with your Github account, create a new project for xoreos. In the project settings, I have configured:

Custom configuration .yml file name: .appveyor.yml
Skip branches without appveyor.yml: check
Rolling builds: check

I left all the rest to the default settings.

There might be something to do with the notifications, but I believe this can be configured in the .appveyor.yml, like for Travis. The file reference is available here: https://www.appveyor.com/docs/appveyor-yml/

@DrMcCoy
Copy link
Member

DrMcCoy commented Oct 13, 2016

Okay, merged with 71c748f (I did change the build version number, though, just so that it fits with our versioning scheme a bit better).

Let's see if it works. :)

@DrMcCoy DrMcCoy closed this Oct 13, 2016
@DrMcCoy
Copy link
Member

DrMcCoy commented Oct 13, 2016

Can you do this for xoreos-tools and Phaethon, too?

xoreos-tools should, I guess, be relatively straight-forward. It also doesn't depend on Boost at the moment, but pulling that in is on the TODO list, to have access to Boost's smart pointers, etc.

Phaethon might be more work, though, since it also depends on wxWidgets.

@DrMcCoy
Copy link
Member

DrMcCoy commented Oct 13, 2016

Hmm, well, that build there failed with a connection time out while trying to fetch iconv... I'll restart :P

@berenm
Copy link
Contributor Author

berenm commented Oct 13, 2016

Yeah, there are some connectivity issues with dependencies hosted on sourceforge... I enabled the cache mechanism in order to workaround them, and to speed up the build a little bit, but it requires a successful build at least to start caching things.

Otherwise, it could use mirrors but I didn't spend too much time looking into it.

@berenm
Copy link
Contributor Author

berenm commented Oct 13, 2016

I'll try to see what I can do for the other repositories.

@DrMcCoy
Copy link
Member

DrMcCoy commented Oct 13, 2016

If I want to explicitly disable an MSVC warning (like C4514, "unreferenced inline function has been removed"), I just have to add 4514 to the WARNINGS_DISABLE variable in CMakeLists.txt, right?

Because to me, this warning looks very useless and spams quite a lot.

@DrMcCoy
Copy link
Member

DrMcCoy commented Oct 13, 2016

Errm, hmm, for some reason, you're building with /W3, but the CMakeList by default adds /W4. Maybe that should be changed instead?

@berenm
Copy link
Contributor Author

berenm commented Oct 13, 2016

I don't think there is any specific compilation flags in the appveyor integration. Whatever is added in the CMakeLists should be taken into account in addition to the default MSVC flags.

I personally don't know anything at all about MSVC switches anyway :).

@DrMcCoy
Copy link
Member

DrMcCoy commented Oct 13, 2016

Interestingly, that commit just now also didn't change anything. Maybe I'm just confused?

Please have a look at https://ci.appveyor.com/project/DrMcCoy/xoreos/build/0.0.4%2BAppVeyor.4 , which looks very spammy with lots of warnings flags that shouldn't be enabled with anything less than /W4 (if I'm reading the MSVC online docs right).

As is, that unfortunately makes the log very not useful, because useful warnings are being drowned out. And AppVoyer even truncates it at a certain point. :/

@berenm
Copy link
Contributor Author

berenm commented Oct 13, 2016

I'm looking at it right now, it's kind of surprising because I don't remember anything like that at all when I did my builds. If you look at my latest build before the PR it wasn't that verbose: https://ci.appveyor.com/project/berenm/xoreos/build/1.0.229

I was based on an older master so maybe is it it?

@DrMcCoy
Copy link
Member

DrMcCoy commented Oct 13, 2016

Ooh, yes, I did change something. I did add compiler flags, including "-Wall". I only meant to do that for non-MSVC, but, yeah, there's no guards around it and I guess MSVC picks that up as well.

Entirely my bad, then.

@DrMcCoy
Copy link
Member

DrMcCoy commented Aug 20, 2017

Hmm, for some reason AppVeyor broke. Seems to be during compilation of xvid if I'm reading this correctly?

I pushed a new branch set to an old commit that used to compile correctly but now fails.
Here's the failing log: https://ci.appveyor.com/project/DrMcCoy/xoreos/build/0.0.4+AppVeyor.237
And this is the old non-failing log, same commit: https://ci.appveyor.com/project/DrMcCoy/xoreos/build/0.0.4+AppVeyor.218

But in the earlier log, it seems it got the old binaries from cache, so it probably actually broke way earlier?

@berenm, If you find some time, could you check what's the problem there? Thanks! :)

@berenm
Copy link
Contributor Author

berenm commented Aug 21, 2017

I think this should be it: #157

@DrMcCoy
Copy link
Member

DrMcCoy commented May 5, 2018

For some reason, the build now randomly breaks during, I think, OpenAL compilation?
@berenm, could you take a look? Thanks!

The error message would be here: https://ci.appveyor.com/project/DrMcCoy/xoreos/build/0.0.4+AppVeyor.509#L346

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants