Make server mode work on Windows #930
Labels
P2
We'll consider working on this in future. (Assignee optional)
platform: windows
type: feature request
Comments
damienmg
added
P1
bazel-io
pushed a commit
that referenced
this issue
Mar 22, 2016
…e to Windows. Progress towards #930. -- MOS_MIGRATED_REVID=117799006
bazel-io
pushed a commit
that referenced
this issue
Apr 19, 2016
Work towards #930. With this, it's conceivable that server mode works on Windows to some degree (I haven't tried, though, because there are many issues that need to be fixed) -- MOS_MIGRATED_REVID=120202037
bazel-io
pushed a commit
that referenced
this issue
Apr 19, 2016
Drive-by fix: eliminate the GRPC messages from the console by passing a null logging function. This also prepares us for the time when multiple commands will be running, because then we'll need to tell which command exactly we want to interrupt. Work towards #930. -- MOS_MIGRATED_REVID=120203008
bazel-io
pushed a commit
that referenced
this issue
Apr 19, 2016
Work towards #930. -- MOS_MIGRATED_REVID=120205147
bazel-io
pushed a commit
that referenced
this issue
Apr 27, 2016
AF_UNIX doesn't work on Windows, so it doesn't make much sense to try. Progress towards #930. -- MOS_MIGRATED_REVID=120912873
bazel-io
pushed a commit
that referenced
this issue
Apr 28, 2016
This change makes it possible to build Bazel with itself in server mode. Progress towards #930 . Does not completely fix it because there are still a bunch of issues that need to be taken care of, but it's usable. -- MOS_MIGRATED_REVID=120994369
bazel-io
pushed a commit
that referenced
this issue
Apr 28, 2016
This is still fallout from a bad merge I did yesterday. More progress towards #930. -- MOS_MIGRATED_REVID=121006319
bazel-io
pushed a commit
that referenced
this issue
Apr 28, 2016
This is so that only one server instance is started up if two clients are started in a workspace that doesn't have a running server yet. More work towards #930. This may break Windows in case flock() doesn't work there as expected. In anticipation of this, locking is moved to blaze_util_platform.h / blaze_util.cc . -- MOS_MIGRATED_REVID=121013078
bazel-io
pushed a commit
that referenced
this issue
May 2, 2016
- Made the control flow much simpler and more understandable - Added some documentation about the interplay of the client and the server - Abstracted out POSIX mechanisms from blaze.cc so that they can be implemented properly on Windows - Added assertions that the methods on BlazeServer are called when they should be Polish for #930. -- MOS_MIGRATED_REVID=121256601
bazel-io
pushed a commit
that referenced
this issue
May 2, 2016
…l -9 is actually a server process. This should be implemented for other OSes, too, but OS X seems to lack a procfs and it's not clear how to discover anything about a process based on its PID and of course, Windows is a wholly different cup of tea. More work for #930. -- MOS_MIGRATED_REVID=121262673
|
I hereby declare this bug as fixed. Server mode doesn't work really well on Windows yet due to #1212 , but that's a separate (and unfortunate) issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The client and the server communicate using a truly bizarre protocol involving Unix domain sockets. We should also take the opportunity to revamp that.
The most obvious candidate is a TCP port on 127.0.0.1 (or ::1), except that it would be a security issue on multiuser systems.
The text was updated successfully, but these errors were encountered: