Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable Windows build of habitat-sim #84

Closed
wants to merge 1 commit into from

Conversation

cegbertOculus
Copy link

Motivation and Context

The Windows build was not functioning. This change enables Windows builds.

How Has This Been Tested

Built on Windows with "python setup.py install" and run with "build/viewer /path/to/data/scene_datasets/habitat-test-scenes/skokloster-castle.glb"

Types of changes

  • Docs change / refactoring / dependency upgrade
  • [x ] Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have completed my CLA (see CONTRIBUTING)
  • I have added tests to cover my changes.
  • All new and existing tests passed.

@facebook-github-bot facebook-github-bot added the CLA Signed Do not delete this pull request or issue due to inactivity. label Jun 20, 2019
src/esp/assets/PTexMeshData.cpp Outdated Show resolved Hide resolved
src/esp/assets/FRLInstanceMeshData.cpp Outdated Show resolved Hide resolved
src/esp/assets/GenericInstanceMeshData.cpp Outdated Show resolved Hide resolved
src/esp/gfx/PTexMeshShader.cpp Outdated Show resolved Hide resolved
@@ -7,7 +7,7 @@ cmake_minimum_required(VERSION 3.10)
project(esp)

if(MSVC)
add_definitions(/DNOMINMAX)
add_definitions(/DNOMINMAX /D_USE_MATH_DEFINES /DEIGEN_DONT_ALIGN_STATICALLY)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is _USE_MATH_DEFINES needed for? Does Habitat code need it or rather some dependency? If Habitat, we have our own constants for that, if 3rd party code, I'd prefere to have that specified in src/deps/CMakeLists.txt instead.

Copy link
Author

@cegbertOculus cegbertOculus Jun 21, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Three projects (nav, gfx, assets, all in src/esp) try to include deps/sophus/sophus/common.hpp and fail to build because M_PI is undefined.

I could define _USE_MATH_DEFINES in each of their respective CMakeLists.txt?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cegbertOculus if sophus is the only culprit, perhaps we can have the define go along with the inclusion of sophus at https://github.com/facebookresearch/habitat-sim/blob/master/src/cmake/dependencies.cmake#L26

Copy link
Author

@cegbertOculus cegbertOculus Jun 21, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From what I can tell, the inclusion of sophus in dependencies.cmake just specifies where to include the sophus files from, and I can't define anything with that inclusion. Maybe it would make sense to put it in src/cmakelists.txt where the projects are added? Like this:

add_subdirectory(esp/nav)
if(MSVC)
target_compile_definitions(nav PUBLIC _USE_MATH_DEFINES )
endif()

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, you're right, I believe. Yes, it should be fine to add conditional target defines as above. Perhaps also with a short comment above the block stating that this is done for the sophus dependency, just for readability

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at Sophus' own CMakeLists, it sets it implicitly for the sophus target -- so I think the cleanest option is to explicitly link to the sophus target instead of relying just on it being inside the global include path? Like

target_link_libraries(nav 
  PUBLIC 
    ... 
    sophus)

and similar for gfx and assets. Then we could even remove the global include path for Sophus, I think -- in any case I'm planning to do that as part of #42.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Explicitly linking didn't work, so I've just added:

if(MSVC)
  # Define common math constants if we compile with MSVC
  target_compile_definitions(assets INTERFACE _USE_MATH_DEFINES)
endif (MSVC)

to the cmakelists.txt for nav, gfx, and assets. Is that acceptable?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PUBLIC instead of PRIVATE? I assume those definitions are needed when compiling the library itself as well. And please mention it's because of Sophus, otherwise this knowledge gets lost and somebody might remove it again in the future.

src/esp/gfx/WindowlessContext.cpp Outdated Show resolved Hide resolved
@cegbertOculus
Copy link
Author

Thanks for the feedback so far. I'll be out of the office for 2 weeks, so I'm putting this on hold for now, but I will pick it up again in 2 weeks.

@cegbertOculus
Copy link
Author

New revision pushed. All issues have been resolved. However, this won't yet run on Windows as some changes are needed in magnum-bindings (mosra/magnum-bindings#2).

Copy link
Collaborator

@mosra mosra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The mosra/magnum-bindings#2 part is merged now, so this could be ready to land -- can you update the corrade/magnum/... submodules to latest to pull those changes?

if(MSVC)
# Define common math constants if we compile with MSVC. This is needed because of Sophus.
target_compile_definitions(assets PUBLIC _USE_MATH_DEFINES)
endif (MSVC)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just endif(), repeating the condition is considered a bad practice nowadays.

Same in the other two cases.

@lostmsu
Copy link

lostmsu commented Oct 30, 2019

@cegbertOculus merged your changes on top of v0.1.3, also replaced most usages of shlex (which I suspect is invalid for Windows paths) with passing simple lists of arguments. See https://github.com/lostmsu/habitat-sim/commits/windows

However, command-line build on Windows from a conda environment fails due to a problem with compile_commands.json:

...
-- Found Magnum: <CLONE_PATH>/src/deps/magnum/src
-- Configuring done
-- Generating done
-- Build files have been written to: <CLONE_PATH>/build/Release
error: [Errno 2] No such file or directory: 'build\\Release\\compile_commands.json'

compile_commands.json are nowhere to be found.

It generates the solution file though, which I can build from Visual Studio. But after that I am unsure how to proceed with setup.

@erikwijmans
Copy link
Contributor

The logic here: https://github.com/facebookresearch/habitat-sim/blob/master/setup.py#L323
likely needs to be updated for windows.

@HeterCol
Copy link

HeterCol commented Jan 9, 2020

@cegbertOculus merged your changes on top of v0.1.3, also replaced most usages of shlex (which I suspect is invalid for Windows paths) with passing simple lists of arguments. See https://github.com/lostmsu/habitat-sim/commits/windows

However, command-line build on Windows from a conda environment fails due to a problem with compile_commands.json:

...
-- Found Magnum: <CLONE_PATH>/src/deps/magnum/src
-- Configuring done
-- Generating done
-- Build files have been written to: <CLONE_PATH>/build/Release
error: [Errno 2] No such file or directory: 'build\\Release\\compile_commands.json'

compile_commands.json are nowhere to be found.

It generates the solution file though, which I can build from Visual Studio. But after that I am unsure how to proceed with setup.

Excuse me, I want to know how the problem 'compile_commands.json does not exist' can be solved. I have meet the same problem.

@lostmsu
Copy link

lostmsu commented Jan 9, 2020

@liuxinzhu0353150307 I simply opened solution file under build\Release (I think it was esp.sln) in Visual Studio and finished the build there.

@HeterCol
Copy link

HeterCol commented Jan 9, 2020

@liuxinzhu0353150307 I simply opened solution file under build\Release (I think it was esp.sln) in Visual Studio and finished the build there.

So have you built it successfully?And you can run the platform on Windows?

@HeterCol
Copy link

HeterCol commented Jan 9, 2020

@liuxinzhu0353150307 I simply opened solution file under build\Release (I think it was esp.sln) in Visual Studio and finished the build there.

So have you built it successfully?And you can run the platform on Windows?

Actually, I don't find the .sln file in 'buile\Release', so I don't know how to do next.

@cegbertOculus
Copy link
Author

@liuxinzhu0353150307 My memory is a little hazy, but I think I just made an empty compile_commands.json file.

@HeterCol
Copy link

@liuxinzhu0353150307 My memory is a little hazy, but I think I just made an empty compile_commands.json file.

so I only need to create an empty file 'compile_commands.json'?

@cegbertOculus
Copy link
Author

so I only need to create an empty file 'compile_commands.json'?

I think it just needs one line with:
[]

@eundersander
Copy link
Contributor

Closing this old PR. We can create a new PR from this branch if there's renewed interest.

@anas-zafar
Copy link

@eundersander , are we able to run this on windows?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed Do not delete this pull request or issue due to inactivity.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants