Support Windows platform

[alanjds]

google#311 opened by @retsyo on May 18, 2017

I am using mingw32 with msys2 on windows
So, any way to let grumpy support windows? Thanks

USR@USR-PC MINGW32 /r/grumpy-master
$ make
build/src/__python__/os/module.go:257: undefined: syscall.SYS_FCNTL
build/src/__python__/os/module.go:265: undefined: syscall.F_GETFD
make: *** [build/stdlib.mk:1453: build/pkg/windows_amd64/__python__/os.a] Error 1

[alanjds]

Comment by trotterdylan
Saturday May 27, 2017 at 14:58 GMT

---

Thank you for reporting this! If you comment out fdopen() in lib/os/__init__.py and the other usages, does everything else compile?

./lib/os/__init__.py:def fdopen(fd, mode='r'):  # pylint: disable=unused-argument
./lib/os_test.py:    os.fdopen(fd)
./lib/os_test.py:  f = os.fdopen(fd, 'w')
./lib/os_test.py:    os.fdopen(fd)
./lib/tempfile_test.py:  f = os.fdopen(fd, 'w')

Unfortunately, there's no easy way at present to do platform-specific compilation of the Python sources in the stdlib. The trouble is that the native imports (from __go__.foo import bar) translate into statically importing and referencing Go package members so even if you check the platform in Python code (e.g. if sys.platform == 'win32': ...) the static compilation will still fail. This needs a bit more thought.

[alanjds]

Comment by retsyo
Sunday May 28, 2017 at 03:04 GMT

---

no, after commenting out all codes with fdopen, nothing changed

$ make
build/src/__python__/os/module.go:253: undefined: syscall.SYS_FCNTL
build/src/__python__/os/module.go:261: undefined: syscall.F_GETFD
make: *** [build/stdlib.mk:1453: build/pkg/windows_amd64/__python__/os.a] Error 1

[alanjds]

Comment by trotterdylan
Sunday May 28, 2017 at 03:11 GMT

---

Sorry, I meant comment out all the fdopen usages so you can then remove the syscall imports that are causing problems in lib/os/__init__.py.

[alanjds]

Comment by retsyo
Sunday May 28, 2017 at 05:37 GMT

---

ok, it works now.

[alanjds]

Comment by trotterdylan
Thursday Jun 01, 2017 at 03:20 GMT

---

Cool, thanks for confirming. With the work I'm doing on sockets I think there will be additional platform specific code that will probably break Windows, so it'd be good to start figuring out how we can properly support multiple platforms.

The easiest option off the top of my head is to have a grumpy.platform (name TBD) Go package that has platform-specific source files that provides a consistent interface for things like sockets and file descriptor operations.