Per rule profiling configuration

[guibou]

Is your feature request related to a problem? Please describe.

Building with profiling can be dramatically slow (#438). This forced us to disable profiling build in a client codebase (#1129) because building with -c dbg was taking many hours.

I'd like a way to enable profiling only for a few selected targets. This will allows me to profile builds and pay the huge build time only for a few selected subset of targets.

Describe the solution you'd like

I can imagine an haskell_library and haskell_binary rule argument enable_profiling, which, if set, override the global setting.

haskell_toolchain will have a similar flag, which, if set, override the bazel -c dbg setting.

Describe alternatives you've considered

Switching back to fast profiling build, as discussed in #438, can be a solution. This is the solution used by cabal and stack right now.

We can also just stay as we are and accept the long build time. Please also note that the current situation is not flexible because linked to the -c option, which is, in my opinion, too global to be interesting. I'd like to be able to combine different set of flags (using --config) to build the codebase the way I like it. For example, I may want a really fast haskell build, but an optimised C++ build, or profiling only on C++, but not on Haskell, or profiling only on a few subset of targets.

Additional context

I can do this development if I receive the green light, I don't want to start something not approved.

[aherrmann]

I think user defined build settings could be a good solution to this. We could define a profiling build setting, say @rules_haskell//haskell:profiling, that defaults to False and can be switched to True on the command-line by passing --@rules_haskell//haskell:profiling=True. That would be the global switch.

Additionally, we could define an attribute, say profiling, and a transition that checks that attribute and if present flips the profiling configuration. This would allow per target profiling mode configuration.

In the past @ulysses4ever tried to use user defined build settings to control the worker mode. Back then it was not possible to define build settings in external workspaces (like @rules_haskell) due to bazelbuild/bazel#9177. However, I've checked on Bazel 2.1, and it now seems to be possible to use this feature for that use-case. See bazelbuild/bazel#9177 (comment).

See here for an example using user defined build settings (based on @ulysses4ever's original example).

[guibou]

I had never been able to understand transition despite reading the documentation page a few time. I have the feeling that it is used to propagate an information in the dependency tree. For example, if you have A -> B -> C (with C which depends on B which depends on A), you may use a transition such as a change of setting on B (e.g. profiling = True) will automatically force A to have profiling = True (or any other setting). Am I correct?

What does this solution gives us than the more straightforward (e.g. the one I understand) does not?

[aherrmann]

The user defined build setting allows to have a separate flag controlling profiling mode for Haskell targets. I.e. it decouples this from -o dbg. Having this as a command-line flag seems more convenient than having it be a toolchain flag, at least it's closer to the -o dbg interface.

You're description of transitions looks correct.

There are two aspects that make transitions look like a good fit for the profiling use-case:

1. You only have to set profiling = True on B and A will also be available in profiling mode for B as well. With a manual attribute you'd have to go through the dependency graph yourself to do this and it would also affect other targets, e.g. if there is a target D that depends on A.
2. With 1:2+ transitions you can get access to multiple versions of a dependency. In profiling mode GHC will only produce static libraries, not dynamic ones. However, for template Haskell you'll need dynamic libraries (at least with the dynamic RTS). With a 1:2+ transition you could request both the non-profiling and the profiling configurations of your dependencies and use one for template Haskell and the other for linking.

[aherrmann]

The user defined build setting allows to have a separate flag controlling profiling mode for Haskell targets. I.e. it decouples this from -o dbg.

I think this is still a valid point and makes a build-setting an attractive option.

However, in light of bazelbuild/bazel#13281 transitions don't seem to be a viable option at the moment.