Benjamin Peterson
unread,Nov 21, 2017, 2:31:33 AM11/21/17Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to László Csomor, Damien Martin-Guillerez, dsl...@google.com, bazel-dev
Thanks for the reply.
On Mon, Nov 20, 2017, at 09:04, László Csomor wrote:
> Griaß di' Benjamin,
>
> Our current plan with runfiles on Windows is to keep the status quo, i.e.
> write a MANIFEST file and not create any symlinks or copy any files.
Excellent. I propose cr.bazel.build/21873 then to clean out some of the
vestigal code for actually creating runfiles trees on Windows.
>
> I've been working on adding helper libraries that implement the actual
> MANIFEST reading logic. An implementation for sh_* rules is already
> available, I'm working on moving it into @bazel_tools, then on updating
> the
> sh_{binary,test} launcher on Windows to automatically source this file,
> so
> the user code can just call rlocation("path/to/runfile") and get an
> absolute path back. I'd like to implement such libraries for other
> languages too, at least Python and Java, though I haven't committed to
> doing it yet.
>
> As for build-runfiles-windows.cc, I believe we don't plan to implement
> anything there. Bazel uses build-runfiles on Linux/macOS, it reads the
> runfiles manifest and creates the symlink tree. AFAIK we added
> build-runfiles-windows.cc to not have break the hardcoded dependency on
> build-runfiles, but Bazel doesn't actually use this utility on Windows.
Ah, I see. I suppose we could select() out build-runfiles from the
embedded tools on Windows to avoid the erroring stub c++ file, but it's
probably not worth it.