Is there any way to exclude certain targets from "all" under certain conditions?

[ahyangyi]

Is there any way to exclude certain targets from "all" under certain conditions?
By conditions I mean the config_settings that could be used in select(). For example, most of my code could be cross-platform but a certain library would be x86_64-only. Is there a recommended way to mark that x86_64-only library so that I can bazel build //...:all --cpu=armv7a without worrying about that one library?

Currently I'm using a wrapper function which basically wraps everything with select:

        deps = if_x86_64(deps),
        srcs = if_x86_64(srcs),
        data = if_x86_64(data),
        hdrs = if_x86_64(hdrs),
        copts = if_x86_64(copts),
        defines = if_x86_64(defines),
        includes = if_x86_64(includes),
        linkopts = if_x86_64(linkopts),
        textual_hdrs = if_x86_64(textual_hdrs),

where if_x86_64 is a function that returns a select. So when building under armv7a, this x86_64-only library becomes an empty one and will not create any error.

However, this approach doesn't work well because select cannot be included inside another select.

So, is there any mechanism that I overlooked that could be used to help the situation? If not, will recursive select be supported in some future version of bazel?

[hermione521]

@lberki if I understand correctly, we don't have such a feature?

[lberki]

No, we don't. The parsing of :all happens before Bazel know what CPU things are compiled for, so it's not possible to do this.

What may work is to create a target in place of :all that you always build and has a select, e.g.:

filegroup(
    name = "build_me", 
    srcs = [":a", ":b"] + select({
        ":x86_64": [":c"],
        "//conditions:default": []),
)

This, of course, requires an explicit list of targets, which is not optimal.

[ahyangyi]

Um, then here's another question: is there any plan to support nested selects?

As far as I understand it, allowing selects to nest does not naturally produce O(n^2) behavior, nor will cause any inefficiency, as long as the selects are properly used. So it does not naturally contradict with any Bazel philosophy. Allowing selects to nest would make my helper functions transparent.

[ahyangyi]

Sorry. I just noticed I cannot re-open this issue, and my last question has strayed too far from the main topic.

Therefore, I opened another at #1623 .

[gregestren]

Note we have some support for CPU-based skipping now:

https://groups.google.com/d/msg/bazel-discuss/U6sFbPWiXGM/_hjddzwdFwAJ