Yesterday I installed the new build20. As I didn't want to uninstall or overwrite my other installations (build19 and intermediate versions) I installed it to a different folder. And I made a backup of the old settings folder. Then I created a new folder for the build20 settings and added --homedir=C:\winprogs\Widelands-build20\wlsettings to the shortcut. Unfortunately the game didn't start. Nothing visible happened, and after a while Windows Error Reporting wanted to connect to the internet (blocked by my firewall). When I remove the --homedir option from the shortcut the game starts immediately. Creating the subfolders replays ... didn't change anything.

I remember that I managed to get it running with build-8670, but there have been similar problems at the beginning, too. Unfortunately I don't remember what I did to get it working

Maybe it helps to set \ instead of \ because one \ is an special sign for windows.

No, that doesn't help. Well, it shouldn't help anyway. \ is used at the beginning of a path in certain cases, like a network path (\server\share\folder), but not for a folder starting with c:... Of course in C you need \ to output a single \ because it is otherwise used for special characters like \n odr \t.

I had a look at the source where the homedir option is processed in wlapplication.cc. That happens quite early in WLApplication::WLApplication(int const argc, char const* const* const argv)

First it is checked with FileSystem::get_homedir() if one of four folders accessible by environment variables is available and writable. Note that FileSystem::get_homedir() returns a . otherwise.

The commandline is parsed. If there is a --homedir option then that value is used.

In setup_homedir() it is checked if the specified folder exists, otherwise it should be created.

Well, that's what I read, but I can't tell if all these commands work as expected. There are some output messages using std::cout and log("...") but even if I start widelands from a command window I don't see any output. The only thing I get is the version information, but only if I redirect stdout to a file using >bla.txt.

And as I already mentioned, the following works for an older build (after trying a bit, and maybe creating the folder manually):

Has anybody used that homedir option sucessfully with build 20? Is it possible to get those debugging messages somewhere?

BTW the stdout.txt file of build8670 contains as second line Adding home directory: c:\winprogs\Widelands-8670\wlsettings. As I don't see that with build20 that could be a hint that the problem is in the first few of the quoted lines of code (maybe commandline parsing?). Just a daring guess...

Thanks GunChleoc! I didn't create a bug report because I wasn't (and still am not) sure if the problem is on my side (PC, ...) or a general one. It seems the --homedir option isn't used much. But I'd say it's the best way to have several versions in parallel.

Ok, now I tried to use the datadir option instead. Just out of curiosity. And this works with build 20.

Is it difficult to set up a build environment for Windows? I don't need to create a full installer. It would be sufficient to be able to compile and link to widelands.exe. Then I could try add some more debug output and see if I can find what's wrong. I had a quick look at the corresponding wiki page (https://wl.widelands.org/wiki/BuildingWidelandsUnderWindowsNew/). Is that still valid for build20?

When I look at the mentioned changes in setup_homedir of revision 8816 there are now different and more tests. And there is an additional call to set_logging_dir(homedir_). I don't see any of the messages which are made using std::cout. Does that mean those branches of the code are not reached? Or are those messages just not displayed in the command window?

You will need to downgrade boost - CMake does not have a rule for detecting Boost version 1.70 yet. Yes, the error messages for this suck and are totally non-obvious, but I didn't find a way to make them better.

Do not mix your downloaded zip with the bzr command, that can leave you with a state that doesn't match the branch and also makes it more difficult for us to help you if you should end up in an unexpected state. To get the Build 20 branch: