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
base: master
from

Conversation

Projects
None yet
2 participants
@berenm
Contributor

berenm commented Oct 13, 2016

@DrMcCoy

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy Oct 13, 2016

Member

Neat, thanks! :)

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

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

This comment has been minimized.

Show comment
Hide comment
@berenm

berenm Oct 13, 2016

Contributor

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/

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy Oct 13, 2016

Member

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. :)

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

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy Oct 13, 2016

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy Oct 13, 2016

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@berenm

berenm Oct 13, 2016

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@berenm

berenm Oct 13, 2016

Contributor

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

Contributor

berenm commented Oct 13, 2016

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

@DrMcCoy

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy Oct 13, 2016

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy Oct 13, 2016

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@berenm

berenm Oct 13, 2016

Contributor

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 :).

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy Oct 13, 2016

Member

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. :/

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

This comment has been minimized.

Show comment
Hide comment
@berenm

berenm Oct 13, 2016

Contributor

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?

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy Oct 13, 2016

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy Aug 20, 2017

Member

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! :)

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

This comment has been minimized.

Show comment
Hide comment
@berenm

berenm Aug 21, 2017

Contributor

I think this should be it: #157

Contributor

berenm commented Aug 21, 2017

I think this should be it: #157

@DrMcCoy

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy May 5, 2018

Member

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

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