Transitions and unwanted identical build of multiple targets

[pehe...@gmail.com]

Our product can be built with a large number of variants, it is both different platforms but also many variants for test.

We have started to use transitions to be able to test all variants with a single "bazel test ..."

Now we have realized that all targets are built in a separated output trees for each transitions.

The problem is also described at https://docs.bazel.build/versions/master/skylark/config.html#user-defined-transitions.

The documentation also mention a TODO regarding the problem.

Are there any plans for reducing the number of built targets when using transitions?

Here is an example with how we see the problem.

The rule example() use a transition where the bool flag "c1" is set to true or false.

Two targets are created, it is only the "bin" target that is actually using the build setting but all common code is built into two separated output trees one for "c1" = True, and one for "c1" = False. 

load("@rules_cc//cc:defs.bzl", "cc_binary")

load(":test.bzl", "example")

load("@bazel_skylib//rules:common_settings.bzl", "bool_flag")

cc_binary(

    name = "bin",

    srcs = ["application.c"],

    copts = select({

        ":c1==True": ["-DC1_APP"],

        "//conditions:default": [],

    }),

    deps = ["//transitions/common"],

)

config_setting(

    name = "c1==True",

    flag_values = {":c1": "True"},

)

bool_flag(

    name = "c1",

    build_setting_default = True,

)

example(

    name = "app",

    c1 = False,

    input = ":bin",

)

example(

    name = "c1_app",

    c1 = True,

    input = ":bin",

)

[Greg Estren]

Hi Peter,

Is your main concern the actual duplicate work of building each target twice? Or that multiple bazel-out/ trees exist, and bazel-bin only references one of them? Or both?

In your specific case it's conceivably straightforward to prevent //transitions/common from duplicating, although it may require some core Bazel dev work. One possible workaround could be to add a transition to "deps" that sets the bool_flag bag to some standard value, maybe modeled loosely on something like https://github.com/bazelbuild/examples/tree/master/rules/starlark_configurations/cc_test.

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/df9b52ac-6f52-4101-944a-ac78fa69aea0n%40googlegroups.com.

[pehe...@gmail.com]

Hi!

The main concern is the duplicated work, so if one transition is used in one test and another transition in another test no build artifacts can be reused between them. The config options used are often deeper in the dependency chain than just in the BUILD file for the test so setting them back to the original value where it is not used will be quite tricky.