Summary:
Python may also be found at these paths, let's thus make sure that getdeps
built Python binaries are searching for python.dll in these paths.
Reviewed By: ikriv
Differential Revision: D37043501
fbshipit-source-id: 3de396f64b59256c1ce31c3b3da6b49e3f1f8838
Summary:
After some experimenting, it is a little awkward if we want to specify a relative path based on the executable location. We'd need to add a bunch of path calculations to make it right, and I don't think the added complexity is really worth the effort.
As a result, let's just remove the use of relative path, and if we ever want to ship a copy of Python distribution, we can place it under the same directory as the binary.
Reviewed By: chadaustin
Differential Revision: D22394180
fbshipit-source-id: 86d27f6d16a03fe08826b5e5eafcef2a1c77997f
Summary:
In EdenFS's latest Windows package. We are seeing DLL import errors coming from `asyncio` as it requires a system native module `_overlapped.pyd`.
The underlying cause is because when we build EdenFS CLI on Sandcastle, we are linking with Python 3.6.2. The Python36.dll shipped with the EdenFS package is also coming from that version.
However, on Windows laptop. We have Python 3.6.3. Since we are not shipping the Python system libraries with us. It uses the libraries installed in the system, and it attempts to import the `_overlapped.pyd` located at `C:\Pythone36\DLLs\`. This version is compiled against Python 3.6.3, which is incompatible with the Python36.dll we are using.
----
To resolve this, we need either ship an embedded copy of Python along with EdenFS, or teach EdenFS to use the Python distribution installed in the system. This commit tweaks the executable we prepend to the archive created with zipapp to locate `Python3.dll` dynamically. This allows us to use the Python installed in the system so we can avoid the version mismatch issue.
With this setup, we can also be shipping an embedded Python version along with EdenFS, and the Python loader can look for that path. This is demonstrated with the relative DLL loading `..\python`.
In theory, we can have a package structure like this:
```
.
├── python
│ ├── ....
│ └── python3.dll
└── bin
├── ...
├── edenfsctl.exe
└── edenfs.exe
```
Reviewed By: xavierd
Differential Revision: D22325210
fbshipit-source-id: 96a3f9503e7865a5f9d95710ff13f019afcf04f1
Summary:
This commit resolves an issue with our zipapp executables
on Windows that meant that the only reliable way to start them was
to use the fully path to the executable.
The root cause is that the __wargv array is produced by parsing the
process command line into an array, and if you ran `watchman-wait -h`
__wargv[0] would have `watchman-wait` rather than the fully qualified
path to the executable that the zipapp plumbing requires.
The fix is to ask the system for the fully qualified path and ensure that
that gets set as both argv[0] AND argv[1].
Reviewed By: xavierd
Differential Revision: D21190350
fbshipit-source-id: eeb95084592d30a028a93b2b03877f8cc6c72729
Summary:
On Windows, compile a small C executable to prepend to the zip file, to allow
the resulting executable files to be run directly on Windows, without needing
to explicitly invoke the Python interpreter to run the output file.
Reviewed By: wez
Differential Revision: D17733616
fbshipit-source-id: 989a93851412d0bbe1e7857aa9111db082f67a4c
