Currently Online

Latest Posts

Topic: Usage of the --homedir option

fuchur
Joined: 2009-10-07, 14:01
Posts: 183
Ranking
Widelands-Forum-Junkie
Location: Germany
Posted at: 2019-05-07, 19:00

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 face-sad.png

Any hints what to do are greatly appreciated.

System: Windows 7 64 Bit

Edited: 2019-05-07, 19:02
Top Quote
kaputtnik
Avatar
Joined: 2013-02-18, 20:48
Posts: 1684
Ranking
One Elder of Players
Location: Germany
Posted at: 2019-05-07, 19:31

I guess you need forward slashes for the path:

--homedir=C:/winprogs/Widelands-build20/wlsettings

?


Top Quote
fuchur
Joined: 2009-10-07, 14:01
Posts: 183
Ranking
Widelands-Forum-Junkie
Location: Germany
Posted at: 2019-05-07, 23:12

kaputtnik wrote:

I guess you need forward slashes for the path:

--homedir=C:/winprogs/Widelands-build20/wlsettings

Thanks for the quick response. Unfortunately that doesn't change anything. In my other configuration for build8670 it works with backslashes.

I checked the rights of the folder, but there is nothing suspicious. I'm owner and have full access.

I will investigate it further when I have more time.


Top Quote
ModellbahnerTT
Joined: 2009-07-19, 11:58
Posts: 57
Ranking
Likes to be here
Posted at: 2019-05-08, 00:12

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

Edited: 2019-05-08, 00:13
Top Quote
fuchur
Joined: 2009-10-07, 14:01
Posts: 183
Ranking
Widelands-Forum-Junkie
Location: Germany
Posted at: 2019-05-08, 22:37

ModellbahnerTT wrote:

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)

#ifdef _WIN32
     homedir_(FileSystem::get_homedir() + "\\.widelands"),
#else
     homedir_(FileSystem::get_homedir() + "/.widelands"),
#endif
     redirected_stdio_(false),
     last_resolution_change_(0) {
    g_fs = new LayeredFileSystem();

    parse_commandline(argc, argv);  // throws ParameterError, handled by main.cc

    if (commandline_.count("homedir")) {
        log("Adding home directory: %s\n", commandline_["homedir"].c_str());
        homedir_ = commandline_["homedir"];
        commandline_.erase("homedir");
    }
#ifdef REDIRECT_OUTPUT
    if (!redirect_output())
        redirect_output(homedir_);
#endif

    setup_homedir();

I think that means the following:

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

C:\winprogs\Widelands-8670>widelands.exe --homedir=c:\winprogs\Widelands-8670\wlsettings

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


Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 2883
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2019-05-09, 09:46

Changes since build8670 that possibly affect this:

I have created a bug report so that we can track this https://bugs.launchpad.net/widelands/+bug/1828355

Edited: 2019-05-09, 09:49

Busy indexing nil values

Top Quote
fuchur
Joined: 2009-10-07, 14:01
Posts: 183
Ranking
Widelands-Forum-Junkie
Location: Germany
Posted at: 2019-05-09, 23:13

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?


Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 2883
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2019-05-10, 08:48

Yes, that page is still valid for Build 20.

You can even use the ./compile.sh script as long as you use the -a or -r option, because AddressSanitizer is not available on Msys2.

The way that logging works is that the logger will write everything into stdout.txt, which is sitting in the homedir. Since you have homedir trouble, that makes things difficult.

We only use std::cout in situations where the logger might not be available etc, and for the command line help.

The reason that we do it like that is that one could install widelands into the Program Files and play without needing administrator privileges.


Busy indexing nil values

Top Quote
fuchur
Joined: 2009-10-07, 14:01
Posts: 183
Ranking
Widelands-Forum-Junkie
Location: Germany
Posted at: 2019-05-10, 22:01

Ok, thanks a lot, I'm about to try to build widelands.

Installing Msys2, the toolchain and packages was no problem.

Then I didn't use the bzr command but copied the source directory I already downloaded as .bzip file (and of course extracted it) somewhere. But then the configuration of cmake resulted in errors.

CMake Error at cmake/WlFunctions.cmake:78 (wl_include_system_directories):
  wl_include_system_directories Function invoked with incorrect arguments for
  function named: wl_include_system_directories
Call Stack (most recent call first):
  cmake/WlFunctions.cmake:176 (_common_compile_tasks)
  src/CMakeLists.txt:26 (wl_library)

There were a lot of them, concerning always the same function but with a different call stack. The function in WLfunctions.cmake looks the following:

function(wl_include_system_directories TARGET DIR)
  _include_directories_internal(${TARGET} ${DIR} TRUE)
endfunction(wl_include_system_directories TARGET DIR)

Should I try to clone the repository using bzr? And if yes, how do get build20 instead of trunk?

I tried to call ninja afterwards, but it complained about the missing build.ninja. I guess that was not created because of the cmake errors.

Update: Now I used bzr and downloaded trunk. But the same cmake errors appear.

Edited: 2019-05-11, 10:41
Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 2883
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2019-05-11, 12:42

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.

wget http://repo.msys2.org/mingw/%MINGWSUFFIX%/mingw-w64-x86_64-boost-1.69.0-2-any.pkg.tar.xz && pacman --noconfirm -U mingw-w64-x86_64-boost-1.69.0-2-any.pkg.tar.xz

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:

bzr branch lp:widelands/build20

Launchpad displays these commands for every branch, see https://code.launchpad.net/~widelands-dev/widelands/build20


Busy indexing nil values

Top Quote