Open guibou opened 4 years ago
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 https://github.com/bazelbuild/bazel/issues/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 https://github.com/bazelbuild/bazel/issues/9177#issuecomment-621090904.
See here for an example using user defined build settings (based on @ulysses4ever's original example).
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?
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.
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 https://github.com/bazelbuild/bazel/issues/13281 transitions don't seem to be a viable option at the moment.
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
andhaskell_binary
rule argumentenable_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
andstack
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.