OpenMW 0.26.0

Anything related to PR, release planning and any other non-technical idea how to move the project forward should be discussed here.
Post Reply
User avatar
gus
Posts: 390
Joined: 11 Aug 2011, 15:41

Re: OpenMW 0.26.0

Post by gus » 02 Sep 2013, 22:27

yeah I'm not completly sure why this error occures, but I solved it by moving constructors from light.cpp to light.hpp. I did not commited these changes because I was not sure if it was only caused by my specific instalation or by a more general problem. Besides, these kind of changes is kindof ugly.

User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: OpenMW 0.26.0

Post by Zini » 03 Sep 2013, 10:54

For the future, can we please try to get these kinds of problems sorted out early? That this is showing up now, close to the release, is kinda a big problem.

Well, I don't know what is going on there. Can someone do a bisect to figure out which commit triggered this problem?

User avatar
Ace (SWE)
Posts: 850
Joined: 15 Aug 2011, 14:56

Re: OpenMW 0.26.0

Post by Ace (SWE) » 03 Sep 2013, 13:21

gus wrote:yeah I'm not completely sure why this error occures, but I solved it by moving constructors from light.cpp to light.hpp. I did not commited these changes because I was not sure if it was only caused by my specific instalation or by a more general problem. Besides, these kind of changes is kindof ugly.
Right, I think this could be because of MSVC being pedantic in a certain way. Just like the fact that according to MSVC, a function taking a declared struct Foo won't link if given a defined class Foo.
Maybe templated classes need to have their constructor defined in header to compile properly, wouldn't surprise me.

Built now anyway, moved the constructor definition from source to header in lights.[ch]pp so have some RC builds:

32-Bit
64-Bit

User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: OpenMW 0.26.0

Post by Zini » 03 Sep 2013, 13:36

Right, I think this could be because of MSVC being pedantic in a certain way. Just like the fact that according to MSVC, a function taking a declared struct Foo won't link if given a defined class Foo.
Maybe templated classes need to have their constructor defined in header to compile properly, wouldn't surprise me.
We are not dealing a class template here. Just a class derived from an instantiated class template. I am fairly sure that there is no requirement to have the definition of the constructor in the current translation unit to use that class.

If you want to go for that workaround for now, I am okay with that. But we need to figure out what is going wrong here. Might be a bug in MSVC or something else. This "fixing things without knowing what is wrong" gives me the creeps.

User avatar
Ace (SWE)
Posts: 850
Joined: 15 Aug 2011, 14:56

Re: OpenMW 0.26.0

Post by Ace (SWE) » 03 Sep 2013, 13:43

Zini wrote:If you want to go for that workaround for now, I am okay with that. But we need to figure out what is going wrong here. Might be a bug in MSVC or something else. This "fixing things without knowing what is wrong" gives me the creeps.
Fixing things without knowing what's wrong is something I've had to do many times while working with MSVC, lots of undocumented pedantitites like this exist in it. Might be by design and with a compiler warning that's turned off, or it might be a bug. Either case we need to do as it wants so I guess we'll have to do with this workaround for now.

Also, since I did these builds over remote desktop I haven't been able to test them myself.

User avatar
Greendogo
Posts: 1460
Joined: 26 Aug 2011, 02:04

Re: OpenMW 0.26.0

Post by Greendogo » 03 Sep 2013, 14:58

Zini wrote:For the future, can we please try to get these kinds of problems sorted out early? That this is showing up now, close to the release, is kinda a big problem.
This, I think, is fundamental problem with how we do RCs, in regard to Windows builds. I assume, with the Linux builds, people are constantly testing it as the month's work goes on, fixing problems as they come up. But the Windows build pretty much just gets built once for testing, per version. And that's during the RC phase.

If we had a chronologically regular point along the work flow where we built Windows test versions, I bet it would cut down on Windows RC problems. This would make it easier to pinpoint when a problem happens, and enough time to file a bug-report during THAT version, instead of the next. Like a weekly build?

Could we make that happen for 0.27.0? Like a build every Friday or Saturday or something?

User avatar
WeirdSexy
Posts: 611
Joined: 15 Sep 2011, 18:50
Location: USA

Re: OpenMW 0.26.0

Post by WeirdSexy » 03 Sep 2013, 15:01

Greendogo wrote: If we had a chronologically regular point along the work flow where we built Windows test versions, I bet it would cut down on Windows RC problems. This would make it easier to pinpoint when a problem happens, and enough time to file a bug-report during THAT version, instead of the next. Like a weekly build?

Could we make that happen for 0.27.0? Like a build every Friday or Saturday or something?
Not to mention it would make it easier for me to do videos :)

User avatar
Ace (SWE)
Posts: 850
Joined: 15 Aug 2011, 14:56

Re: OpenMW 0.26.0

Post by Ace (SWE) » 03 Sep 2013, 15:33

I guess something like that could be done, just have someone remind me to make a build every now and then :)

Been wanting to put up a buildbot for other things so I might try my hand at making an OpenMW builder at that time, but it's in the future and all my builds are manually done right now.

User avatar
psi29a
Posts: 4992
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: OpenMW 0.26.0

Post by psi29a » 03 Sep 2013, 15:53

Nightlies....

Time for travis/jenkins/etc to start giving us binaries. ;)

K1ll
Posts: 154
Joined: 06 Aug 2011, 21:54

Re: OpenMW 0.26.0

Post by K1ll » 03 Sep 2013, 16:45

Linux targz package RC1

32 Bit
64 Bit

Post Reply