Issue #31 new

Add Windows support.

tkeller
repo owner created an issue

Florent Teichteil-Koenigsbuch recently provided a patch (which is attached) that allows to run the planner on Windows. We should evaluate the planners performance on Windows before we incorporate the (awesome, thanks Florent!) addition into the main repo.

Comments (14)

  1. tkeller reporter

    Once this is included, we should make sure that all future changes still compile and run on Windows. As not all developers have access to a Windows machine, we have to find a way how to make this automatically. We have a Windows machine running here in Basel where the FastDownward developers perform compilation and performance tests as well, and it should be possible to create a script that compiles PROST automatically on that machine and sends an email if compilation fails. We can also use that machine to run some instances and see if the output is as expected. Note that, even though it would be nice to also have performance tests, we have no access to a Windows grid such that this is not a possibility.

    If you agree on this, we therefore need the following scripts (as part of this issue):

    1. A script that checks out PROST and compiles it on the Windows machine here in Basel whenever code is pushed to the prost (or better prost-dev?) repository.
    2. A second script that runs some (small) instances and checks if the output is as desired.
  2. Đorđe Relić

    There is a problem with fdd.h library included in search_engine.h in line 16. There is no patch instructions for handling that and I cannot find windows version of this lib. The library can be found at BuDDy webpage. Is it an option to download the lib and include it directly if target OS is Windows?

  3. tkeller reporter

    There is some discussion on this topic on the archive of the buddy-users mailing list which can be found here: https://sourceforge.net/p/buddy/mailman/buddy-users/. It seems that it is possible to compile the library if the right compiler is used, so I see two possibilities how to proceed (and neither includes the library into our code base):

    1. find out how to compile libbdd on Windows and describe the process on the Windows installation wiki page
    2. remove all BDD functionality from the Windows version - anyway, there isn't much left and I don't know how important it is
  4. Đorđe Relić

    I found a way to install BuDDy to windows after a short discussion and the answer was to install it from a website of a developer that works on porting Linux libraries to Cygwin via cygport. This might be a good solution as long as this guy keeps his website up with all the libs.

    As the second proposition for solving the problem concerning BuDDy (removing BuDDy functionality from Windows version), these are the variables and methods that are being used:

    // BDD related methods
    bdd stateToBDD(KleeneState const& state) const;
    bdd stateToBDD(State const& state) const;
    bool BDDIncludes(bdd BDD, KleeneState const& state) const;
    
    // The BDDs where dead ends and goals are cached
    static bdd cachedDeadEnds;
    static bdd cachedGoals;
    

    So, in case that solution is better, their importance should be discussed.

    However, before everything, we should decide on which ways should this port to windows be implemented (one or multiple). Possible ways to do it are using:

    Cygwin and MinGW don't work good together, it's possible but their communication is complicated and relying to this combination is a bad thing in my opinion. I started porting the app with Cygwin (and succeeded to install BuDDy with it) but current patch notes suggest using flag -mwin32 (which also doesn't cover 64 bit OS case, if that is even needed?) hence the compiler is trying to access MinGW compiler. I did not find a way to install BuDDy with MinGW and buddy-user mailing lists do not give any answers and are obsolete.

    So, in my opinion, it would be good to chose the way how porting to windows should be done and if multiple ways are to be done, in which order and priority, so that we would have a version for windows soon. It would also be good to contact Mr. Teichteil and discuss his initial idea and work like that.

    One more note, which different versions of Windows should be covered? Cygwin stopped support for Windows versions older than Windows 7 and from Windows 10 on, there is Bash on Windows that enables users to run native Linux apps on windows without any additional setup (I already tested it and it works like a charm :)).

    Sorry for a long comment, I hope that it is at least clear as it is long.

  5. tkeller reporter

    However, before everything, we should decide on which ways should this port to windows be implemented (one or multiple).

    If we leave the external dependencies out of the discussion for now (BuDDy can be removed for Windows easily), I think we should aim for a true Windows version, which is, in my understanding, running the code from Visual Studio. As far as I understand it, Cygwin emulates a Linux-like environment, and I think that the code should run there already.

    It would also be good to contact Mr. Teichteil and discuss his initial idea and work like that.

    I'll point Florent to this discussion

    One more note, which different versions of Windows should be covered?

    I honestly have no idea about Windows version. Just start with the one you have, and then we'll see if it also runs on other (newer) version.

  6. Đorđe Relić

    tkeller Is there a particular reason why State is defined as struct in states.h file in rddl_parser and like a class in search? I'm experiencing issues with linking and if I change it to class and make all methods public, some of the linking issues go away.

    Also, the patch doesn't cut it for all the changes that need to be done. One of the issues is with timer.h class and the methods used there. Are those modifications done (and compatible in parser and search)? If yes, I can proceed and adapt them to Windows, if not, maybe that should be done firstly.

    For now, I'm generating VS project successfully but am still setting proper flags for correct compilation of the project.

  7. tkeller reporter

    Is there a particular reason why State is defined as struct in states.h file in rddl_parser and like a class in search? I'm experiencing issues with linking and if I change it to class and make all methods public, some of the linking issues go away.

    No, there is no reason for that, it's historical and will be changed with issue #33 anyway, so go ahead and change it accordingly.

    One of the issues is with timer.h class and the methods used there. Are those modifications done (and compatible in parser and search)?

    Which modifications do you mean? Currently, no one is working on issue #33, so you can go ahead and adapt the search and parser code.

    Also, the patch doesn't cut it for all the changes that need to be done. [...] If yes, I can proceed and adapt them to Windows, if not, maybe that should be done firstly.

    I feared so. Please go on and make sure that everything that is crucial (and the timer is crucial for the learning part of the IDS heuristic) runs on Windows.

  8. Đorđe Relić

    tkeller Building and compilation in CMake on Windows now works. Haven't tested anything yet, but I noticed that current build.py script, while it compiles the project, doesn't create .sln file that represents Visual Studio solution file (which when double-clicked opens VS project). CMake can create .sln, with plain running of cmake command so if that is still the idea, I can add that to build.py script. Note: Current build behavior is identical to the one of FastDownward.

    The code is online. Testing is due to be done, checking if all corresponding flags are included and adding comments to CMakeLists files that explain Windows tags.

  9. tkeller reporter

    Building and compilation in CMake on Windows now works. Haven't tested anything yet, but I noticed that current build.py script, while it compiles the project, doesn't create .sln file that represents Visual Studio solution file (which when double-clicked opens VS project). CMake can create .sln, with plain running of cmake command so if that is still the idea, I can add that to build.py script. Note: Current build behavior is identical to the one of FastDownward.

    Since I don't use VS, I do not have any preference. If you were to develop PROST in VS, would you like the solution file to be generated automatically? If so, add it. Otherwise, leave it.

    The code is online. Testing is due to be done, checking if all corresponding flags are included and adding comments to CMakeLists files that explain Windows tags.

    Sounds great, I'll try to have a look at the code as soon as possible. In the meanwhile, we should think about doing some performance tests. If we want to do this properly, we should run all the benchmarks on a single machine, even if it takes a couple of days. We could use our groups Windows PC for that.

  10. Đorđe Relić

    Since I don't use VS, I do not have any preference. If you were to develop PROST in VS, would you like the solution file to be generated automatically? If so, add it. Otherwise, leave it.

    Personally, I would never use Visual Studio for C++ development. Even now I did everything from Visual Studio Command Prompt and a random editor. There can be a short instruction (make a folder, change to that folder and run cmake PROST_LOCATION/src/) for generating .sln file and others needed for opening PROST in VS so we can just simply add this in the wiki.

  11. tkeller reporter

    I tried to compile the planner on Windows (using some VS shell) and got the following error message:

    C:\thomas-prost>python build.py
    Building configuration release
    -- The C compiler identification is MSVC 19.0.23026.0
    -- The CXX compiler identification is MSVC 19.0.23026.0
    -- Check for working C compiler: C:/Program Files (x86)/Mic
    14.0/VC/bin/cl.exe
    -- Check for working C compiler: C:/Program Files (x86)/Mic
    14.0/VC/bin/cl.exe -- works
    -- Detecting C compiler ABI info
    -- Detecting C compiler ABI info - done
    -- Check for working CXX compiler: C:/Program Files (x86)/M
    o 14.0/VC/bin/cl.exe
    -- Check for working CXX compiler: C:/Program Files (x86)/M
    o 14.0/VC/bin/cl.exe -- works
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Detecting CXX compile features
    -- Detecting CXX compile features - done
    -- Found BISON: C:/win_flex_bison-latest/bison.exe (found v
    -- Found FLEX: C:/win_flex_bison-latest/flex.exe (found ver
    CMake Warning at search/CMakeLists.txt:25 (message):
      BuDDy lib was not found.  Since this is a Windows build B
      included in the build.
    
    
    CMake Error: The following variables are used in this project, but they are set
    to NOTFOUND.
    Please set them or make sure they are set and tested correctly in the CMake file
    s:
    FL_LIBRARY (ADVANCED)
        linked by target "rddl-parser" in directory C:/thomas-prost/src/rddl_parser
    
    -- Configuring incomplete, errors occurred!
    See also "C:/thomas-prost/builds/release/CMakeFiles/CMakeOutput.log".
    Built configuration release failed due to CalledProcessError
    
  12. Đorđe Relić

    The distribution from which you installed Flex and Bison doesn't contain FL_LIBRARY while the when you install flex from the link I provided, you have the needed library and searching for it is covered with CMake.

  13. Log in to comment