Bazel needlessly downloads un-select()'d external deps

[jart]

Assume I have the following:

genrule(
    name = "clang_format_extract",
    srcs = select({
        ":darwin": ["@clang_macosx//file"],
        "//conditions:default": ["@clang_linux_x86_64//file"],
    }),
    # ...
)

config_setting(
    name = "darwin",
    values = {"cpu": "darwin"},
    visibility = ["//visibility:private"],
)

Bazel will download @clang_macosx even if I'm Linux, and vice versa. This forces Linux users to pay the price of an additional 139MB download + disk space that they don't need.

It would be nice if Bazel was smart enough to not take into consideration references to external dependencies, within select() clauses that aren't selected.

[kchodorow]

Unfortunately, the WORKSPACE file is evaluated before select can be used. As a workaround, you could change it to @clang and then create a repository_rule that downloaded the right clang based on what uname returns.

[abergmeier]

@jart is creating a clang_repository = repository_rule( not an option for you? That's at least the way we usually handle this.
In WORKSPACE you would then only have a clang_repository( name = "clang" ).

[jart]

I can employ that workaround. Thank you.

[abergmeier]

@kchodorow Curious whether you would see using repository_rule as a workaround or whether this would be the intended approach.

[jart]

It's hard to say. I think the select solution is already ugly. I do however wish it did the right thing. I'm not sure how I'm going to use uname in the correct manner yet. It's probably going to be a lot more code for me to write the custom repo rule. But I don't care as long as it saves the user a gigantic download.

[kchodorow]

I see it as a workaround, but probably a long-term one. I think we do need to "fix" select (or something like it) to be usable from the WORKSPACE file. Maybe as we make it easier to define a "platform" this will work itself out.

[jart]

Having select() work from a workspace file would be awesome.

On Thu, Jul 7, 2016 at 9:52 AM, Kristina [email protected] wrote:

I see it as a workaround, but probably a long-term one. I think we do need
to "fix" select (or something like it) to be usable from the WORKSPACE
file. Maybe as we make it easier to define a "platform" this will work
itself out.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#1482 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AADAbg7jYdwk0ZCYSTMA6eSXHX8dJcDOks5qTQSngaJpZM4JGUye
.

[kchodorow]

This has come up before, I filed #1485 as a general FR.