Custom compilation modes

[vladimir....@gmail.com]

Hi.

I wonder, can we have custom compilation modes? Basically, it is great thing that one can specify compiler flags in CROSSTOOL files and depend on features.

But sometimes `opt`, `dbg` and `fastbuild` are not enough, and in this case we have to create custom `--define` settings, wrap around `cc_binary`, `cc_library` and so on and implement custom `compilation_mode` and add options `select`ing proper `config_setting`.

Is there any chance we could use custom values for `compilation_mode` (better) or use `define` values as a selector (worse) right in CROSSTOOL, without touching `cc_binary`/`cc_library`?

Kind regards,
Vladimir.

[László Csomor]

/cc @Marcel Hlopko @Rosica Dejanovska @Pedro LF  -- do you know if this is possible?

--
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

--
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/fdf1c56f-5eb7-4240-aa0e-36998a32ea60%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marcel Hlopko]

Hi Vladimir,

I see features as a way to implement that. What is there that you need that features cannot do? Maybe there are approaches that you didn't try, or maybe I have a blind spot somewhere.

Thanks!

--

Marcel Hlopko | Software Engineer | hlo...@google.com | 

Google Germany GmbH | Erika-Mann-Str. 33  | 80636 München | Germany | Geschäftsführer: Geschäftsführer: Paul Manicle, Halimah DeLaine Prado | Registergericht und -nummer: Hamburg, HRB 86891

[vladimir....@gmail.com]

Agree, features is a great thing.

Minor drawbacks of using them are:
1) One cannot have mutually exclusive features (just like `compilation_mode`).
2) One should abandon using `compilation_mode` at all or specify both `features` and `compilation_mode` in command line and remember which combinations (of features and modes) can stack.

A major thing is that sometimes it may be needed to add dependency if some feature is enabled, but for now one cannot use `select()` between `features`.

For example, linking against special debug library in some special debug mode.

Kind regards,
Vladimir.

On Thursday, December 13, 2018 at 1:44:45 PM UTC+3, Marcel Hlopko wrote:
> Hi Vladimir,
>
>
> I see features as a way to implement that. What is there that you need that features cannot do? Maybe there are approaches that you didn't try, or maybe I have a blind spot somewhere.
>
>
> Thanks!
>
>
> On Tue, Dec 11, 2018 at 9:27 AM László Csomor <laszlo...@google.com> wrote:
>

> /cc ...@Marcel Hlopko ...@Rosica Dejanovska ...@Pedro LF  -- do you know if this is possible?

[Marcel Hlopko]

Hi Vladimir,

1) I believe you can - use provides: field (https://docs.bazel.build/versions/master/crosstool-reference.html#feature-relationships)

2) Yes this will cause some overhead. For example compilation modes do a little bit more than just enabling compiler flags, on linux, when building an executable binary, we use PIC objects in fastbuild/dbg, and NOPIC objects in opt. All should be hackable from the crosstool, but it will be interesting.

3) You can do that by using FeatureFlagInfo (cowboy code warning):

def _feature_enabled(ctx):
    toolchain = find_cpp_toolchain(ctx)
    feature = ctx.attr.feature_name
    feature_configuration = cc_common.configure_features(...)
    return [config_common.FeatureFlagInfo(value = cc_common.is_enabled(feature_configuration, feature))]

feature_enabled_flag = rule(
    implementation = _feature_enabled,
    attrs = {
        "_cc_toolchain": attr.label(default = Label("@bazel_tools//tools/cpp:current_cc_toolchain")),
    },
)

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/44808143-7dc8-45a3-aee3-de3de9c71143%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[vladimir....@gmail.com]

Thank you!

Just in case somebody else will be interested, I provide working code (Bazel 0.20.0):
```
def _feature_enabled(ctx):
toolchain = ctx.attr._cc_toolchain[cc_common.CcToolchainInfo]
feature = ctx.attr.feature_name
feature_configuration = cc_common.configure_features(cc_toolchain = toolchain)
result = cc_common.is_enabled(feature_configuration=feature_configuration, feature_name=feature)
return [config_common.FeatureFlagInfo(value = str(result))]

feature_enabled_flag = rule(
implementation = _feature_enabled,
attrs = {
"_cc_toolchain": attr.label(default = Label("@bazel_tools//tools/cpp:current_cc_toolchain")),

"feature_name": attr.string()
},
)
```

I have another question though. How would I use this provider info? Ideally I would want to make high-level `select` in one of the `BUILD` files.

I can make a rule where I can read this result but I do not currently understand how to make a dependency enabled or disabled depending on this value.

Kind regards,
Vladimir.

[Marcel Hlopko]

Hi Vladimir,

you can just use create config_setting using flag_values: https://source.bazel.build/bazel/+/master:src/test/shell/bazel/apple/bazel_apple_test.sh;l=295?q=xcode_version_flag&ss=bazel

Then you can use the config_setting in the select.

--
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/50664918-04d4-417c-a455-fd26122467e7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.