Windows build fixes

[Jalle19]

@ksooo how do I trigger Jenkins to build from this branch? Or can you do it for me if you know how?

[ksooo]

Sorry, don't have a clue.

[Jalle19]

@ksooo are you okay with this change in general or should we use the slightly more verbose LogLevel::LEVEL_ERROR and change the other levels too? This change produced the smallest diff which is why I went with it for now.

[ksooo]

should we use the slightly more verbose LogLevel::LEVEL_ERROR and change the other levels too

Yes, I would prefer this, but it's just my personal taste.

[xhaggi]

why not use scoped enumerations

enum class LogLevel {}

This should work IIRC.

[Jalle19]

@xhaggi how will that help?

[xhaggi]

sorry thought it would work, but it seems that it doesn't. You can use camel-case or like you did prefix it.

[Jalle19]

I think I'll use prefixing, will update later.

[Jalle19]

@ksooo okay to merge so we can get Jenkins to build test for us? Or @xhaggi do you have a Windows build environment you can test this branch in?

[Jalle19]

@ksooo build tested on Windows now. I found some other minor issues that I tacked on as separate commits (since the PR is named "build fixes"). Let me know if you want me to separate them into another PR. If not you can push the button.

[Jalle19]

@Glenn-1990 any idea why DEFAULT_APPROX_TIME was an integer? I'm guessing it was a mistake which is why I changed it, feel free to correct me.

[Glenn-1990]

@Jalle19 Yes, there was, the setting is an enum (to toggle between use strict timings - use approximate timings), it's not possible to use a boolean value for an integer enum ;-)

It's possible to use a bool as setting, but then we can only switch feature xy on or off, so we can not switch between 2 features.

[Jalle19]

Okay, I think I get it. Do you think there will be a third option added to this setting any time soon? If I revert the commit then we should also change m_defaultApproxTime to be an integer (it's a boolean with or without my patch). What do you think?

[Glenn-1990]

@Jalle19
No, I don't plan a 3rd option.
I'm not sure if "ReadBoolSetting" and "SetBoolSetting" will work for "autorec_approxtime" as an enum should be read out as int.

If you can confirm that it works, it's ok by me, but otherwise I should leave it as it was before this PR.

[Jalle19]

It's only an enum in the XML, once it reaches C++ it's just a plain 0 or 1 integer. I'll do some runtime testing to make sure though.

[Jalle19]

Semantically it should probably be stored as an integer since it's not a true/false thing, like you said it represents multiple choices. There just happens to be two choices which is what fooled me to go down the boolean route.

[Jalle19]

Just dropped the commit that changed types of a setting, this is now good to go. I'll merge later if no one complains.