Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows: implement ijar for MSVC #2157

Closed
laszlocsomor opened this issue Dec 1, 2016 · 7 comments
Closed

Windows: implement ijar for MSVC #2157

laszlocsomor opened this issue Dec 1, 2016 · 7 comments
Assignees
Labels
P1 I'll work on this now. (Assignee required) platform: windows type: feature request
Milestone

Comments

@laszlocsomor
Copy link
Contributor

Goal:

bazel build //third_party/ijar/...:all --cpu=x64_windows_msvc

should succeed and have a working Windows implementation.

This is a prerequisite for #2107.

@laszlocsomor laszlocsomor added platform: windows P2 We'll consider working on this in future. (Assignee optional) type: feature request labels Dec 1, 2016
@laszlocsomor laszlocsomor self-assigned this Dec 1, 2016
@ulfjack
Copy link
Contributor

ulfjack commented Dec 1, 2016

Technically, you could disable ijar on Windows to achieve #2107 instead of blocking on this.

@laszlocsomor
Copy link
Contributor Author

hmm :) well i already have the CLs lined up for it so meh
but thanks!
any ideas for porting or disabling build-runfiles / process-wrapper?

bazel-io pushed a commit that referenced this issue Dec 1, 2016
This change takes us closer to compiling ijar,
thus Bazel, with MSVC.

See #2107 and #2157

--
MOS_MIGRATED_REVID=140717828
bazel-io pushed a commit that referenced this issue Dec 1, 2016
This change takes us closer to compiling ijar,
thus Bazel, with MSVC.

Also update the StatFile method added by
unknown commit to report any errors.

See #2157
See #2107

--
MOS_MIGRATED_REVID=140719249
@ulfjack
Copy link
Contributor

ulfjack commented Dec 1, 2016

I think that we have a Java implementation of build-runfiles. process-wrapper is more complicated, but you could start with a minimal implementation that doesn't do the more advanced stuff we're doing in the Posix version.

bazel-io pushed a commit that referenced this issue Dec 1, 2016
This change takes us closer to compiling ijar,
thus Bazel, with MSVC.

See #2157
See #2107

--
MOS_MIGRATED_REVID=140722341
bazel-io pushed a commit that referenced this issue Dec 1, 2016
zip_main.cc no longer needs <unistd.h>.
This change takes us closer to compiling ijar,
thus Bazel, with MSVC.

See #2157
See #2107

--
MOS_MIGRATED_REVID=140723658
bazel-io pushed a commit that referenced this issue Dec 1, 2016
zip_main.cc no longer needs <unistd.h>.
This change takes us closer to compiling ijar,
thus Bazel, with MSVC.

See #2157
See #2107

--
MOS_MIGRATED_REVID=140724421
@dslomov
Copy link
Contributor

dslomov commented Dec 6, 2016

neither build-runfiles nor process-wrapper are used on Windows.

@dslomov dslomov added this to the 0.5 milestone Dec 6, 2016
@laszlocsomor
Copy link
Contributor Author

@dslomov , are you sure about process-wrapper? It is certainly a dependency of Bazel, do you think we can simply remove it?

@dslomov
Copy link
Contributor

dslomov commented Dec 6, 2016

@laszlocsomor oh sorry there is #1852: we still use it for bazel run but actually we shouldn't.

@laszlocsomor laszlocsomor changed the title Windows: build ijar with MSVC Windows: implement ijar for MSVC Feb 23, 2017
@laszlocsomor
Copy link
Contributor Author

We can now build ijar but many functions say "isn't implemented for windows".

bazel-io pushed a commit that referenced this issue Feb 27, 2017
Instead of writing from / reading to a string,
these variants take a buffer and a size.

These methods will be used from ijar.

See #2157

--
PiperOrigin-RevId: 148635487
MOS_MIGRATED_REVID=148635487
@dslomov dslomov added P1 I'll work on this now. (Assignee required) and removed P2 We'll consider working on this in future. (Assignee optional) labels Feb 28, 2017
bazel-io pushed a commit that referenced this issue Feb 28, 2017
Ijar will use Bazel's file handling logic so that
we don't have to maintain two implementations, and
don't have to copy this code to implement the
Windows/MSVC code path in
third_party/ijar/platform_utils.cc.

See #2157

--
Change-Id: Iec327febb882aeaabae55216d0d06488f7c151ed
Reviewed-on: https://cr.bazel.build/9068
PiperOrigin-RevId: 148770951
MOS_MIGRATED_REVID=148770951
bazel-io pushed a commit that referenced this issue Mar 1, 2017
See #2157

--
PiperOrigin-RevId: 148887981
MOS_MIGRATED_REVID=148887981
bazel-io pushed a commit that referenced this issue Mar 3, 2017
*** Reason for rollback ***

[] has detected that 500 or more targets failed to build at commit 69a127b, each of which successfully built at the prior CL that affected them.
[] double-checked that //javatests/com/google/apphosting/tests/usercode:Security_StubTest
built at 148995024. The verification run was: 
[]
but the same target failed to build at 148995025. The [] link for this run is available here: []
To see all targets that ran, along with their final status, visit: []
Questions? Comments? See the URL.
go/autorollback

*** Original change description ***

ijar: use bazel's file utilities

This change not only implements ijar for Windows
(with MSVC), but also fixes a bug in
mapped_file_windows (path conversion didn't make
the input path absolute, so we could not build
java code with the MSYS-less bazel).

Fixes #2157

--
PiperOrigin-RevId: 148998092
MOS_MIGRATED_REVID=148998092
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P1 I'll work on this now. (Assignee required) platform: windows type: feature request
Projects
None yet
Development

No branches or pull requests

3 participants