Summary: This would use all the available CPUs and speed up the build process.
Reviewed By: strager
Differential Revision: D13563433
fbshipit-source-id: 18b3862ae0c56ae3865c56864b58cf749c844bd4
Summary:
Restructured the Windows code to align with the eden code layout. Plus changed the build location to eden/win/build directory, which is generated by the Windows build script.
eden
\_fs
\_ ...
\_ win
\_fs
\_service
\_utils
\_build (generated by the build script)
Reviewed By: strager
Differential Revision: D10081143
fbshipit-source-id: db9fb25f963d1a9cccb8a8f83646e7e45c87d409
Summary:
Modified the build scripts to use dependencies from D:\edenwin64. This is the location where we will mount the edenwin64.iso.
It also contains changes to compile it with the latest Eden Linux changes plus removed some POC stuff and dependencies from my laptop.
Reviewed By: strager
Differential Revision: D9545688
fbshipit-source-id: e92e34d0af07974845faf9f729e0861fde5af459
Summary:
This diff is first in the series to make Eden work on Windows. It includes:
1. HG backing store and Object store, which provides the capability to talk to mercurial and fetch the file and folder contents on Windows.
2. Subprocess and Pipe definition for Windows.
3. The Visual studio solution and projects files to compile Eden and scm datapack.
Few Important points:
1. Most of the changes to existing code is done under a macro EDEN_WIN so that it doesn't impact on other platform.
2. Sqlite is used for caching the fetched contents. We are not using Rocksdb on Windows.
3. The main function only calls some test code and exit after printing the output.
4. The initializeMononoke code is disabled for Windows because it needs Proxygen to talk HTTP. Will enable this once I get Proxygen and other dependencies working.
5. HgImporter pass Windows handles to hg_import_helper as command line args. The code to convert these handles into fds is in a separate diff.
Reviewed By: wez
Differential Revision: D8653992
fbshipit-source-id: 52a3c3750425fb92c2a7158c2c214a9372661e13
