Why not always generate Cabal macros?

[thumphries]

Currently Cabal-style CPP macros are not generated unless version is set in haskell_library.

I am wondering if it would be reasonable to always generate them. We usually only care about the versions of other libraries, rather than one's own version.

[guibou]

Thank you for this interesting question!

rules_haskell was previously generating Cabal-style CPP macros for all packages, but this leads to macro conflict because package name are named like the name attribute of haskell_library rule, see #414 for the full discussion. For example, if you have haskell_library in //a/b:foo and //c/d:foo, they will be both named foo. This works well until a rule starts to have both package as dependency, because macro are based on the package name, both packages will generate the same macros.

We think that CPP version macros version are not useful in a bazel repository because the point of this kind of repository is to control all the version of all the software used in the build process, so there is no need for special case depending on a specific version, because the user already control the version of the dependencies.

There is an exception for package imported from outside (from hackage for example) which are out of control of the repository owner and may need to use CPP version macros, but these packages have a version, hence the rational behind only activating CPP version macros for packages with a version. Please note that a macro conflict will still appears if two haskell_library with the same name and a non null version attribute are used as dependency of the same rule. #402 proposed to add a warning for that case, but it was closed due to no interest for the feature.

Others possible designs:

• Fully qualify the name of package with the bazel path. I.e, rule @repo//a/b:foo will generate package repo__a_b__foo (naming example) instead of foo. This solutions generates more complicated packages name AND will generate wrongly named CPP version macros for packages imported from outside. For example, if we import the hackage package text in our repository under the path @repo//a/b:text, the package will be named @repo__a_b__text instead of text and CPP version macro will be generated accordingly, which is unexpected and breaks any packages which relies on hackage package names.
• We can decide per package if they will generate CPP version macro during the compilation of another package, when the first package is used as dependency. And the name used in the CPP macro can also be provided as a parameter. This design is the more robust, however that's also the more complex to implement.

Out of curiosity, do you have a use-case for which you'll need Cabal-style CPP macros without version attribute? We may reopen the design discussion with an interesting use-case.

[thumphries]

Thanks for the context. I'll do a bit of reading and get back to you if I have anything constructive 😅

I am using Hazel with a large collection of custom hand-written BUILD files for upstream dependencies. They all need to have their version set in order to case on things like base and bytestring, but they basically never need to export their own macros downstream. So, the version flag becomes more or less a boolean that says "this is a Hackage package that uses CPP".

It feels like version should control whether or not we export macros, rather than whether or not we are able to consume them. I don't know if GHC gives us that level of control, though.

[guibou]

It feels like version should control whether or not we export macros, rather than whether or not we are able to consume them. I don't know if GHC gives us that level of control, though.

GHC does not gives us that power, however we can tell GHC to disable macro AND export macros by ourself, that's totally doable, but more work. Actually, what you propose was discussed when we faced this issue with macro conflict and we decided for a simpler solution.

[Profpatsch]

Is there anything actionable in this PR? I believe there were some further internal discussions on the use of cabal macros.

[guibou]

I'm closing. Feel free to reopen if the current design in a blocker for your workflow.