Merge jml/rules_haskell about rules_haskell HOT 7 CLOSED

@jml thanks for reaching out. Would be great to accelerate development by converging efforts. Happy to add you as a collaborator on this repo if you like.

• @Fuuzetsu is there anything in https://github.com/jml/rules_haskell that hasn't been implemented yet in your monster #14 PR?
• @jml it would be helpful to list the set of features you already supported, and see which ones are missing here and file those as separate tickets. You could then push PR's to fix each of these features by porting your existing code.
• Generating BUILD files à la Gazelle is something we're assuming in our roadmap, which we should flesh out as a document in this repo. There is some wiggle room in the design space here: how fine-grained the dependencies exposed via Gazelle-for-Haskell should be? Let's discuss that as part of a dedicated ticket.

from rules_haskell.

I looked through the source and there's no new functionality or source that we don't already have, I think we have a straight up improvement over it.

from rules_haskell.

Lovely, thanks.

• I'll try to figure out what (if anything) jml/rules_haskell has to contribute & submit PRs.
• I've filed #17 re generating BUILD files.
• Please do share your roadmap. Even if it's a draft, is incomplete, and has typos, it can be very useful for external contributors.
• To set expectations, this is very much a part-time project for me. Don't expect huge acceleration.

from rules_haskell.

• There's a lot of work in #14 so please take that into consideration when looking at stuff to submit. I would treat that as authoritative code. @mboes did you have a chance to look at it? It'd be good to merge into master so we can work off master rather than piling everything on there.
• Great, I put some thoughts there w.r.t. what MVP could feature.
• So far the direction has been taken towards "let's get jni then inline-java projects compiling (which they now do as of weekend in #14). My next goal is to get sparkle to compile. The idea is that these interact with Java so we can use bazel's Java support to build the two languages as a complete product. All feature work I've done has been directly guided by those packages rather than trying to get feature complete rules. I expect that once sparkle works, we will want to step out into more general implementations. mboes suggested trying to build Agda. From my point of view, the roadmap is somewhat like
  • do whatever it takes to get sparkle working
  • do whatever it takes to get Agda working
  • take a step backwards on think about toolchain: for example we may want to start integrating with https://github.com/tweag/rules_nixpkgs such that we don't have to provide a dirty environment with GHC with wired in packages
  • in similar vein, start going backwards in dependency graph and try to package dependencies properly rather than relying on wired-in packages: this more than likely means doing something with
    #17 to generate BUILD files for dependencies off Hackage &c.
• I'm also part-time: about 2, sometimes 3 days of the week but I'll try to reply to any questions sooner than later.

I think toolchain work is very valuable, it's something we'll have to do anyway. The questions here are things like:

• How to set modes? Say, developer wants profiling. This has to propagate down through all the rules. I recently found https://github.com/bazelbuild/rules_go/blob/master/go/modes.rst#id1 which uses something called --features. This will work for simple things.
• How to set non-simple things that propagate down? For example we want to build everything with -O2. Currently I don't know a way. I attempted aspects in the past but it was a huge failure (see comment on 22839bd)
• How to provide and pick different versions of GHC? Pulling down binaries from GHC's site would be the easiest but will it work? rules_nixpkgs is an alternative though a bit heavy. We should provide bazel expressions that let us pull those in or perhaps it will be specified in some different way. This also has to be propagated down.
• What will the UI be for hackage dependencies? I suspect in the end it will be something like what stackage2nix generates: we will generate BUILD files for all dependencies and use https://docs.bazel.build/versions/master/external.html#non-bazel-projects along with work from #17 in coarse mode to create bazel dependencies we can use.

Let me know if you have something specific you're looking to work on, any questions &c.

from rules_haskell.

from rules_haskell.

I have played a little with rules_nixpkgs: I was able to provision bazel with GHC and various tooling like cpphs, hsc2hs &c. I'm unsure what UI to provide to the user there but I'll worry about that after all that works. Part of work here 7bbfa6a ; I'd ignore external_libraries, they will use targets too eventually but I had to revert that due to some bug I thought I caused.

However in general I don't know if we want to use rules_nixpkgs for Official™ toolchain. I'm using it just in general to provision some stuff but for real deal we'll probably want to download official binaries and use those directly: luckily it should eventually be a drop-in replacement which is why I tried this in first place.

from rules_haskell.

Roadmap submitted as #19. Sounds like all other aspects of this ticket have been broken off into separate tickets by now. So closing this one. Feel free to file more.

from rules_haskell.