windows runfiles

[Benjamin Peterson]

Hi all,
It looks like the approach all rules are currently using on Windows to
find runfiles artifacts at runtime is to parse the runfiles MANIFEST.
--experimental_enable_runfiles is automatically "no" Windows. Will this
be the permanent implementation of runfiles on Windows going forward?

In the Bazel code base, there also seems to the beginnings of a
different Windows runfiles implementation (via copying?). For example,
src/main/tools/build-runfiles-windows.cc is simply a stub that always
fails. It would simplify the runfiles implementation a bit if we could
delete this code, so I'm wondering if it's still wanted.

Servus,
Benjamin

[Damien Martin-Guillerez]

+László Csomor +Dmitry Lomov 

--
You received this message because you are subscribed to the Google Groups "bazel-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-dev+...@googlegroups.com.
To post to this group, send email to baze...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-dev/1510208317.1356704.1166616584.61889A3A%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

[László Csomor]

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.

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.

Cheers,

Laszlo

--
László Csomor | Software Engineer | laszlo...@google.com

Google Germany GmbH | Erika-Mann-Str. 33 | 80636 München | Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

On Mon, Nov 20, 2017 at 2:45 PM, Damien Martin-Guillerez <dmar...@google.com> wrote:

+László Csomor +Dmitry Lomov 

On Thu, Nov 9, 2017 at 7:18 AM Benjamin Peterson <b...@benjamin.pe> wrote:

Hi all,
It looks like the approach all rules are currently using on Windows to
find runfiles artifacts at runtime is to parse the runfiles MANIFEST.
--experimental_enable_runfiles is automatically "no" Windows. Will this
be the permanent implementation of runfiles on Windows going forward?

In the Bazel code base, there also seems to the beginnings of a
different Windows runfiles implementation (via copying?). For example,
src/main/tools/build-runfiles-windows.cc is simply a stub that always
fails. It would simplify the runfiles implementation a bit if we could
delete this code, so I'm wondering if it's still wanted.

Servus,
Benjamin

--
You received this message because you are subscribed to the Google Groups "bazel-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bazel-dev+unsubscribe@googlegroups.com.

[Benjamin Peterson]

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.

[László Csomor]

Excellent. I propose cr.bazel.build/21873 then to clean out some of the
vestigal code for actually creating runfiles trees on Windows.

Thanks! I reviewed it, see comments.

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.

Sure. I think we simply never got around to doing this cleanup.