build director on windows

[RussTedrake]

if this proves difficult, then providing the precompiled version as a cmake external project would be a reasonable short-term fallback.

[patmarion]

The tricky part is satisfying the dependencies on the build servers. Director itself builds on Windows, or at least it did build on Windows last year, I might have introduced something trivial since then that will break. I have a virtual machine with VS 2013 building everything, but I haven't launched that virtual machine since last year.

Qt 4.8 - I built this from source. It might be possible to use the official SDK, not sure if there are VS compatibility issues.

VTK 5.10 - I build this from source. I had to patch it using a patch I found on someone's github. I seem to remember the patch had been contributed to the VTK 5.10 release branch but had not been incorporated yet, maybe that's not true. I can launch my virtual machine to dig up the patch if it's not easy to locate.

Python 2.7 - installed the official 32-bit version

NumPy - installed the official 32-bit version https://sourceforge.net/projects/numpy/files/NumPy/1.9.2/numpy-1.9.2-win32-superpack-python2.7.exe/download

I'm sure it's possible to make it work with the 64 bit build of Python and NumPy too. At Kitware I packaged projects with Qt + Python/Numpy 64bit using the binaries, using ones from here:

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

Probably the ParaView packagers can tell you their strategy, which may be building from source, I'm not sure.

[RussTedrake]

Awesome. Thanks for the details @patmarion. I definitely think we want to enable developers (and the build servers) to build director on windows. I don’t think we need to make them all build QT, etc, from source. Perhaps the right cut is to package and host the relevant versions of QT, vtk5.10+patch, and python binaries and bring them in the same way we currently bring in gtk as a precompiled external project? I actually we should do that for the linux/mac versions, too.. because the compile time/complexity of building director (especially vtk) currently dominates all of the feedback I get about the experience of installing drake from source.

[patmarion]

I hear you on that.

I think the goal should be to provide a pre-compiled director for windows and mac users. Eventually we could make a ppa for ubuntu, but I don't think the linux build is difficult because all dependencies are easily apt-get installed. To provide the packages, we'll need the windows build server to compile Director, as this issue calls for.

Just to be clear, Director compiles very quickly. The very long build is homebrew compiling vtk from source. Homebrew does not provide a bottle of vtk5 because we enable the non default --with-qt option. I made a bottle that seems to work as long as you use clang (a gcc bottle could be made, too). So we could test a new system where users brew install the vtk5 bottle I have created. I have posted this elsewhere, but just to repeat, here is how to install vtk5 from the bottle i made:

wget https://dl.dropboxusercontent.com/s/mtacwrjgmtanfaz/vtk5-5.10.1_2.mavericks.bottle.1.tar.gz
brew tap homebrew/science
brew install qt
brew install vtk5-5.10.1_2.mavericks.bottle.1.tar.gz

I can volunteer to get travis-ci to provide Mac packages for Director (I already have it building the package, it just doesn't upload it anywhere). Then Drake's default option for mac/windows can be director from binary, and we add an option to build director from source.

[RussTedrake]

I agree that director itself builds quickly. And we’d like people to be able to modify / contribute to that source. So my feeling is that having the vtk and python precompiled, but director building from source, is the most natural place to make the cut. Great to hear that you’re already close to that. is there a reason I’m not seeing to go all the way to precompiled director? (if so, why not precompiled bullet, precompiled lcm, …, too?)

[RussTedrake]

In fact, our bullet and lcm pods change much much less frequently than director, and are much less likely to be modified by our developer community, so are actually probably much better candidates for distributing as precompiled.

[billhoffman]

Precompiled is difficult because of different compiler versions. But, I guess for now drake depends on VS 2015. Unless it is an executable binaries are hard to do precompiled. I will give it a try and see how it goes with pre-built copies of Qt, python and numpy.

[billhoffman]

New trouble.... VTK 5.10 does not build with VS 2015. http://vtk.1045678.n5.nabble.com/Building-VTK-5-10-with-VS-2015-tt5734890.html. That is what we are using on the build servers.

[patmarion]

Is VS 2013 an option? Some ideas:

1) spin up a build server with VS 2013 that builds and packages Director. Since Director is a standalone executable, this should be usable by all

2) patch VTK 5.10 to build on VS 2015. The patch doesn't need to be pretty. Director only uses a small set of VTK libraries, so basically just need the core to build.

3) upgrade the required VTK version to version 6.x or 7.0. I would love to upgrade the version. The problem will be finding a common version that is easy to install on Linux, Mac, and Windows. On Mac, homebrew has aggressively removed their vtk6 recipe, it has recently been upgraded to vtk 7.0, so homebrew only provides vtk5 and vtk7. Of course, you can pin back the recipe to get version 6.3. On Ubuntu, there is not yet a PPA for version 7. On Ubuntu 14, vtk6 package provides VTK version 6.0, not 6.3. Does anyone at Kitware know about plans to provide a VTK 7 ppa, or whether one already exists?

[billhoffman]

OK, I am looking into creating the patch to build 5.10 with VS 2015. I would like to get you to a newer version of VTK sooner rather than later.

[billhoffman]

There are no Kitware plans for a ppa. We just create the release tar balls and let package maintainers pick them up as they see fit.

[patmarion]

Some more info- the Director superbuild can be told to download and build VTK itself. By default, USE_SYSTEM_VTK is ON, but if you set that to OFF then the superbuild will download VTK from here:

https://github.com/bilke/VTK.git

The default branch of that VTK repo builds on Windows VS 2013. The superbuild will build VTK with Qt and Python support.

The QTDIR environment variable should be set to the Qt install location, for example, C:\Qt\4.8.6 is what I have it set to. That allows CMake to find Qt automatically. Or, you can make sure qmake is in the PATH, that's another method to ensure CMake finds Qt automatically.

If Python was installed with the Python installer, then CMake can find it automatically I think.

[billhoffman]

I have been able to patch VTK 5.10 to work with VS 2015 as well as Qt 4.

[billhoffman]

@patmarion, made some progress. I built VTK5 and qt4 using VS 2015. I had to make this change to PythonQt: https://github.com/commontk/PythonQt/issues/20. I used the superbuild to build. However, when I tried to run I get this error: ./drake-visualizer.exe Traceback (most recent call last): File "", line 1, in File "C:/Users/hoffman/Work/drake/director/distro/superbuild/build/install/lib/python2.7/dist-packages\director\drakevisualizer.py", line 2, in from director import lcmUtils File "C:/Users/hoffman/Work/drake/director/distro/superbuild/build/install/lib/python2.7/dist-packages\director\lcmUtils.py", line 1, in import lcm ImportError: No module named lcm

Looks like I need to build lcm, but if I try to build it using the superbuild I get this error: [8/15] Performing configure step for 'lcm' FAILED: cmd.exe /C "cd /D C:\Users\hoffman\Work\drake\director\distro\superbuild\build\src\lcm-build && C:\Users\hoffman\Work\drake\director\distro\superbuild\build\src\lcm\configure --prefix=C:/Users/hoffman/Work/drake/director/distro/superbuild/build/install && "C:\Program Files (x86)\CMake\bin\cmake.exe" -E touch C:/Users/hoffman/Work/drake/director/distro/superbuild/build/src/lcm-stamp/lcm-configure" 'C:\Users\hoffman\Work\drake\director\distro\superbuild\build\src\lcm\configure' is not recognized as an internal or external command, operable program or batch file. ninja: build stopped: subcommand failed.

[patmarion]

If you set the superbuild option USE_SYSTEM_LCM=ON and USE_LCM=ON then it will search for LCM instead of attempting to download and compile it. Hopefully there would be a way to make the search succeed in finding the installed copy of LCM that has been built from Drake's superbuild.

When USE_LCM is ON, then director will compile additional c++ files that depend on liblcm. But the error you posted is actually a python import error. To resolve that, you have to set the PYTHONPATH environment variable. It should be set to include the directory: [drake-build]/lib/python2.7/site-packages and [drake-build]/lib/python2.7/dist-packages. If the drake-visualizer.exe binary from the install location, [drake-build]/bin, then those paths should be automatically added and you won't have to set PYTHONPATH environment variable. Just to make sure, you should confirm that [drake-build]/lib/python2.7/site-packages/lcm exists, that is the lcm python module location.

[patmarion]

Oh, also when configuring director's superbuild, you should set USE_EXTERNAL_INSTALL=ON and set CMAKE_INSTALL_PREFIX to the drake/build folder.

Here are the exact configuration parameters that drake uses when configuring director via the pod makefile in director/distro/pods/drake-distro/Makefile:

cmake \ -DCMAKE_INSTALL_PREFIX=$(BUILD_PREFIX) \ -DCMAKE_BUILD_TYPE=$(BUILD_TYPE) \ -DCMAKE_PREFIX_PATH:PATH=$(BUILD_PREFIX) \ -DUSE_LCM:BOOL=ON \ -DUSE_LCMGL:BOOL=ON \ -DUSE_SYSTEM_LCM:BOOL=ON \ -DUSE_EXTERNAL_INSTALL:BOOL=ON \ ../../../superbuild

I would attempt with those exact parameters, but possibly set USE_LCMGL to OFF for the first attempt.

[billhoffman]

So, I built it as part of the drake superbuild. However, it still can not find the lcm import. I did have to set this to -DUSE_LCMGL:BOOL=OFF to get it to build.

./build/bin/drake-visualizer.exe File "C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages\director\lcmUtils.py", line 1, in import lcm

Where should the lcm module be, and what is it called? (lcm.py)

[patmarion]

Oh, I suppose it's possible that the lcm python module is not built on windows, or not installed. On Mac/Linux, it is installed here after building LCM:

drake/build/lib/python2.7/site-packages/lcm/

and the lcm/ contents are:

__init__.py
_lcm.so

Where _lcm.so is a C Python module.

But let's try this, edit C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages\director\lcmUtils.py and just comment out the first line which contains "import lcm". It turns out that import is not needed, because drake-visualizer uses a C++ interface class called ddLCMThread, it never uses the lcm python module.

Note, you should actually edit lcmUtils.py in the source dir director/src/python/director/lcmUtils, not the installed copy, because the source copy will replace the installed copy next time you build.

If Director is built with USE_LCM=OFF then you will get an error that ddLCMThread does not exist. But if USE_LCM=ON, then it should work.

You might have other import errors, for numpy or vtk, perhaps, if those are not installed into the PYTHONPATH. If resolving these imports takes a lot of back and forth, maybe it could be helpful to do a screen sharing session so I can help get the imports straightened out

[billhoffman]

I am getting closer....

C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages\director\thirdparty\transformations.py:1901: UserWarning: failed to import module _transformations warnings.warn("failed to import module %s" % name) C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages\director\drakevisualizer.py:18: FutureWarning: The drake python lcmtype bindings have been moved back to the drake package. You may want to upgrade your version of drake warnings.warn("The drake python lcmtype bindings have been moved back to the drake package. You may want to upgrade your version of drake", FutureWarning) Traceback (most recent call last): File "", line 1, in File "C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages\director\drakevisualizer.py", line 19, in import lcmtypes.drake as lcmdrake ImportError: No module named lcmtypes.drake

[patmarion]

Is there a directory named drake in C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages ? That is where the drake Python lcmtypes should have been installed, assuming they were generated with lcmgen during the drake build process.

[billhoffman]

$ cd Work/drake/draketest/build/lib/python2.7/dist-packages/ hoffman@quasar ~/Work/drake/draketest/build/lib/python2.7/dist-packages $ ls director urdf_parser_py

[patmarion]

Is there also a site-packages directory in the python2.7 folder, and does it contain anything? If the drake Python directory is not in there, then it looks like the drake build on Windows may not be invoking lcmgen to generate Python lcmtypes, or not installing them. You could look for a drake/init.py file any place in the drake pod-build dir to see if it was even generated.

[patmarion]

GitHub modified the file name, it's double underscore init double underscore .py

[rdeits]

You can use backticks to prevent github from screwing up your text:

`drake/__init__.py`

[billhoffman]

Even closer...

If I run from the build directory with ./bin/drake-visualizer.exe, it gets farther:

hoffman@quasar ~/Work/drake/draketest/build $ ./bin/drake-visualizer.exe Traceback (most recent call last): File "", line 1, in File "C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages\director\drakevisualizer.py", line 5, in import director.applogic as app File "C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages\director\applogic.py", line 5, in import director.vtkAll as vtk File "C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages\director\vtkAll.py", line 2, in from vtkDRCFiltersPython import * ImportError: DLL load failed: The specified module could not be found.

[patmarion]

Can you locate vtkDRCFiltersPython.dll anywhere? It should have been installed to C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages\director. If you find it was built but installed to the wrong location then that could be a bug in the install rule defined by director.

Just to verify, was VTK built with python enabled? One reason why vtkDRCFiltersPython.dll might not exist is if VTK_WRAP_PYTHON is OFF in VTKConfig.cmake. But Director's superbuild builds VTK with -DVTK_WRAP_PYTHON:BOOL=ON.

[patmarion]

Sorry, the extension of the library should by "pyd" not "dll". You should look for the file:

vtkDRCFiltersPython.pyd

This file is created by the python wrapping code in src/vtk/DRCFilters/CMakeLists.txt on line 170, conditionally executed by if(VTK_WRAP_PYTHON).

[billhoffman]

One step forward, one back... After adding several things to PATH, it finds all the VTK stuff, but I am now back to the original error:

warnings.warn("failed to import module %s" % name) C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages\director\drakevisualizer.py:18: FutureWarning: The drake python lcmtype bindings have been moved back to the drake package. You may want to upgrade your version of drake warnings.warn("The drake python lcmtype bindings have been moved back to the drake package. You may want to upgrade your version of drake", FutureWarning) Traceback (most recent call last): File "", line 1, in File "C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages\director\drakevisualizer.py", line 19, in import lcmtypes.drake as lcmdrake ImportError: No module named lcmtypes.drake

[patmarion]

This is due to the missing drake python lcmtypes module. Were you able to locate it any place? You should look for drake/__init__.py. It should have been installed into C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages.

In case there is a limitation in the drake build system such that this python module is not being generated, then you can work around it temporarily by using this here. Download this link and extract the folder and place it in C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages

https://www.dropbox.com/s/x0jzvlj6ms8c5k8/drake.zip?dl=0

As an aside, this is a somewhat misleading error message, let me explain. The code attempts to import drake, and if that fails, it attempts to import lcmtypes.drake. So the error message is related to lcmtypes.drake, but that's not really the name be concerned about.

[billhoffman]

Actually, it seems to be in here:lib/python/dist-packages/, I tried a copy: cp -r lib/python/dist-packages/* lib/python2.7/dist-packages/

But it still did not work.

Seems to be there now: ls lib/python2.7/dist-packages/drake/ init.py lcmt_quadrotor_input_t.py init.pyc lcmt_quadrotor_output_t.py lcmt_body_motion_data.py lcmt_robot_state.py lcmt_body_motion_data.pyc lcmt_scope_data.py lcmt_body_wrench_data.py lcmt_simulation_command.py lcmt_drake_signal.py lcmt_support_data.py lcmt_driving_control_cmd_t.py lcmt_viewer_command.py lcmt_foot_flag.py lcmt_viewer_draw.py lcmt_force_torque.py lcmt_viewer_geometry_data.py lcmt_joint_pd_override.py lcmt_viewer_link_data.py lcmt_piecewise_polynomial.py lcmt_viewer_load_robot.py lcmt_polynomial.py lcmt_whole_body_data.py lcmt_polynomial_matrix.py lcmt_zmp_com_observer_state.py lcmt_qp_controller_input.py lcmt_zmp_data.py

[patmarion]

Ok. If the drake/__init__.py is in the right place but it is still giving you the same error message, then there could be a bug but the real error message is being suppressed. Let's see if we can get better information. Can you try adding the following statement to the very beginning of drakevisualizer.py at C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages\director\drakevisualizer.py

import drake

Perhaps that will print a more helpful error message than the try/except block on line 14 of that file.

[billhoffman]

Good idea, that found the issue. I had one too many directories in my PYTHONPATH specifically vtk which had an io.py that conflicted with the system one. Once remove, I am back to the lcm issue.

C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages\director\thirdparty\transformations.py:1901: UserWarning: failed to import module _transformations warnings.warn("failed to import module %s" % name) Traceback (most recent call last): File "", line 1, in File "C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages\director\drakevisualizer.py", line 522, in main app = DrakeVisualizerApp() File "C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages\director\drakevisualizer.py", line 385, in init self.drakeVisualizer = DrakeVisualizer(self.view) File "C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages\director\drakevisualizer.py", line 225, in init self.sendStatusMessage('loaded') File "C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages\director\drakevisualizer.py", line 298, in sendStatusMessage lcmUtils.publish('DRAKE_VIEWER_STATUS', msg) File "C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages\director\lcmUtils.py", line 181, in publish getGlobalLCM().publish(channel, message.encode()) File "C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages\director\lcmUtils.py", line 41, in getGlobalLCM return GlobalLCM.get() File "C:/Users/hoffman/Work/drake/draketest/build/lib/python2.7/dist-packages\director\lcmUtils.py", line 22, in get cls._handle = lcm.LCM() NameError: global name 'lcm' is not defined

It also has a scary pop up that says R6034 attempt to load the C runtime incorrectly.

Also, remember we commented out import lcm from the lcmUtils.py file.

[patmarion]

Oh I think it's actually working now, after one more edit to workaround the missing lcm module:

Edit lcmUtils.py again and comment out line 298 where it says:

        lcmUtils.publish('DRAKE_VIEWER_STATUS', msg)

For now we'll just go without that line.

I'll follow up with a fix for the R6034 C runtime error message, it requires a fix which I forgot to commit.

[billhoffman]

I seem to have a different lcmUtils.py than that.
line 298: sha_build_dir = os.path.join(self.build_dir, sha) Only stuff with publish is this: def publishAndWait(channel, message, responseChannel, responseMessageClass=None, timeout=5000): helper = MessageResponseHelper(responseChannel, responseMessageClass) publish(channel, message) return helper.waitForResponse(timeout, keepAlive=False)

def publish(channel, message): getGlobalLCM().publish(channel, message.encode())

[patmarion]

Oh sorry, I gave you a line number in drakevisualizer.py. For lcmUtils.py, comment out line 181.

[patmarion]

To fix the C runtime library warning, edit uuidutil.py and replace it with these contents:

https://github.com/patmarion/director/blob/fix-uuid-utils/src/python/director/uuidutil.py

[patmarion]

Oops, if you comment out line 181, then you need to add a line after it that just says:

pass

So that the function has a body.

[billhoffman]

I found it in drakevisualizer.py and commented it out. I put in the workaround, and it works! Not sure I could reproduce it... But I have a working copy at the moment.

[billhoffman]

I guess now we need the hand edited stuff to get checked into director.

[patmarion]

I can merge the uuid fix. I just opened a pull request here:

https://github.com/RobotLocomotion/director/pull/223

For the lcm modifications, these are only necessary because it appears the the Windows LCM build is not installing the lcm python module, or not generating it. The best fix would be to resolve this in the LCM build. If that is not feasible right now, then I can check in changes to Director that conditionally disable the feature just for Windows.

The last remaining missing feature is the LCMGL part. That could be added if the libbot Windows build is producing the correct library, we haven't looked at that yet.

[billhoffman]

OK, I got lcm to work so I was able to remove all the hacks and get it to run. For the LCMGL part, this is disabled on Windows. https://github.com/RobotLocomotion/drake/blob/master/CMakeLists.txt#L49, seems like director can live without that. Maybe just leave it off by default on the Windows build of director.

[billhoffman]

For VTK I had to create a new fork of VTK to get it to compiler with VS 2015, this also compiles with VS 2013. I put my patch here: https://github.com/billhoffman/VTK/tree/vtk5.10-visual-studio-2013-2015-patches. We could move this fork into https://github.com/RobotLocomotion. Thoughts on where that should live? This one https://github.com/bilke/VTK.git will not work with 2015 only 2013. The VTK folks at Kitware not interested in supporting VTK5, although we might be able to get a tag with the patches I think a RobotLocomotion fork might make the most sense.

[patmarion]

I'm fine with updating the Director superbuild to reference your personal fork of VTK. If @RussTedrake wants to have a VTK fork under RobotLocomotion, that's fine with me, too, I don't have a preference.

Later this year I think it might be a good time to upgrade Director dependencies versions of VTK (6 or 7), Qt 5, and Python 3, but for now I think everything is working well on all the supported platforms. I'm happy you got the build running on VS 2015, that's awesome!

[billhoffman]

An upgrade would be a good idea. Brad King just pointed out that since c++-11 features are being used by drake, the vtk5 that comes pre-compiled on ubuntu will not be something we could use with the newer compiler. So, we would end up having to build VTK 5 anyway. I guess we are getting away with this now because director is being compiled with different compilers than drake. I will put in a PR for director that uses my personal fork of VTK and adds a QT4 external project build. Using this code: https://github.com/Kitware/fletch/pull/24

[sherm1]

@patmarion, @billhoffman: any progress on this? I've been using an old Win32 binary that Russ gave me, and that still works for some simple examples (pendulum, quadrotor). But it doesn't work with Russ's Atlas PR #2164 (not merged yet). (I have pulled, built, and run that in Linux successfully.) I'm thinking I need a newer Director on Windows but my first few attempts at building it have failed. (CMake 3.3.1, VC++ 2015 64 bit, not sure how to get the right VTK and Qt.)

[patmarion]

Sorry, no update from me. I hope that we can configure a Jenkins build server to make nightly Director builds and releases. That server could build VTK and Qt from source, or we could just download pre-compiled binaries of those dependencies to the build server (I might recommend doing it that way). Python is installed with binary installers, and should be found during the LCM build, too.

[billhoffman]

The CI system seems to be stabilizing, so we should be able to focus on this in the next two weeks again. The next step is to update the superbuild in director to use this Qt: https://github.com/Kitware/fletch/pull/24, and this VTK : https://github.com/billhoffman/VTK/tree/vtk5.10-visual-studio-2013-2015-patches. @jonathan-owens is going to be looking at this next.

[jonathan-owens]

Regarding @billhoffman's post above, we actually had to use this Qt in this PR: https://github.com/Kitware/fletch/pull/34. It is not merged yet.

I am building VTK on my local windows machine right now.

[billhoffman]

The PR is now merged into fletch https://github.com/Kitware/fletch/pull/34

[billhoffman]

@sherm1 I have a branch that you can try: https://github.com/billhoffman/drake/tree/director_on_windows right now it hard codes PYTHON_LIBRARY=C:/Anaconda2/libs/python27.lib. I think for windows Anaconda python will make the most sense as it already has numpy built in and there is a 64 and 32 bit version. But this branch on drake should build director as a superbuild, it will take a while as it will build QT and VTK, but it should work.

[sherm1]

Great – thanks, Bill. I’ll give it a try as soon as I can.

Regards,

Sherm

From: Bill Hoffman [mailto:notifications@github.com] Sent: Wednesday, June 8, 2016 2:36 PM To: RobotLocomotion/drake drake@noreply.github.com Cc: Michael Sherman sherm@tri.global; Mention mention@noreply.github.com Subject: Re: [RobotLocomotion/drake] build director on windows (#1786)

@sherm1 https://github.com/sherm1 I have a branch that you can try: https://github.com/billhoffman/drake/tree/director_on_windows right now it hard codes PYTHON_LIBRARY=C:/Anaconda2/libs/python27.lib. I think for windows Anaconda python will make the most sense as it already has numpy built in and there is a 64 and 32 bit version. But this branch on drake should build director as a superbuild, it will take a while as it will build QT and VTK, but it should work.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RobotLocomotion/drake/issues/1786#issuecomment-224736464 , or mute the thread https://github.com/notifications/unsubscribe/AD5g0GJbYD12vSbNSNKtqXmHOIUVQffzks5qJzXVgaJpZM4Hnuj- . https://github.com/notifications/beacon/AD5g0JI2f0gaaVIqOjVSXaAjn4Zaa7_Wks5qJzXVgaJpZM4Hnuj-.gif