Preliminary bazel support.

[Fuuzetsu]

For the most part this should be self-explanatory but there are a couple of things that need to be talked about and resolved in the future one way or another, be it in sparkle/inline-java or rules_haskell.

• inline-java relies on javac. We can provide this trivially through nix. In practice however that's quite useless: in sparkle we want javac with Java part of sparkle in the CLASSPATH. This is because we want to compile Java bytecode during GHC compilation that depends on it. The existing cabal way is to run gradle build before GHC runs, extract and set CLASSPATH that way. With bazel we do not have the luxury of Cabal's setup hooks. This is an awful way to begin with: running another build system during Haskell compilation just seems wrong but the problem remains.
  • We want to build Java part of sparkle with bazel: after all that's the big part of the appeal: bazel has rules for multiple languages so we should be able to use them. This means that ideally we do not want to just say "OK, let's just use nix to compile the Java part: it has the authoritative access to the jars and we can easily refer to them by absolute path by wrapping javac". While this could work, it gives too much to do for nix.
• Even if we were to be able to extract CLASSPATH from sparkle's Java (this is somewhat doable with a custom rule), we still have no way of feeding this into rules_haskell: we don't want to have to have specific Java handling in Haskell rules. It's an implementation detail of inline-java that it's done this way and it'd be wrong to put in code to accommodate this library.
• It seems like we should just provide the javac with the right CLASSPATH already available, somewhat like what we do with GHC.
• All of the above give rise to the hack of providing a toolchain with javac that has a CLASSPATH already set. Then when it comes time to actually use it, we make sure that the jars are in place through rule_haskells data section.
• This is fragile and ungraceful, polluting the build env with a CLASSPATH. It works for this usecase but ideally we don't want it to exist.
• Another thing to discuss is Sparkle.hs. Currently it relies on Paths_ to find sparkle jar which is a Cabal feature. I have put in a workaround where cabal users can keep relying on it but others can use a different main which requires that this is passed in.
• Trying to increase UX for the above build target, I have writted a small wrapper around the binary which fills in this flag for the user with location of the jar produced earlier on in the build. This way user does not manually fiddle with paths.
• This works if we bazel build and ./bazel-bin/sparkle but doesn't work if we try to bazel run. I could not figure out how to get the latter working.

w.r.t. javac: the problem in general is that we want to define a toolchain from a rule that's using the toolchain. I think the best way to solve this would be to use two toolchains:

• toolchain_1 builds sparkle JARs; this toolchain has javac only
• toolchain_2 is created depending on sparkle java target: this toolchain has GHC + javac + CLASSPATH.
• toolchain_2 is used for compiling everything else.

We could have a third toolchain which is just GHC only but it adds a chance that we mix GHC being used &c. (which may be OK).

I am unsure if this approach is doable, I have not explored it yet. It would likely require defining some sparkle_toolchain with appropriate rules_haskell toolchain type.

---

There was also talk about inline-java instead outputting Java files that we could then compile. In theory this would be the nicest way for us as long as we know what it outputs. I don't see however how it would work in practice: as far as I understand, the Haskell compilation relies on the bytecode being produced during compilation and it's used for things (type inferrence?). Further our existing Haskell rules can't accommodate such a stop-start approach: they always expect that a library is produced in the end. We would need some custom rule that only spits out the generated Java files, we'd have to compile those then we still have to figure out how to supply it back to GHC for the rest of the compilation.

[Fuuzetsu]

This is for most part a discussion PR about what approaches we want to take, whether changes in sparkle/inline-java would make things easier &c.

[Fuuzetsu]

Closing in favour of solution through https://github.com/tweag/rules_haskell/issues/80

[facundominguez]

Delete the bazel branch?

[Fuuzetsu]

I'll be updating it with new solution soon hopefully.