Merge jml/rules_haskell

[jml]

This isn’t really an issue, just a way to kick off communications. (Do you have a mailing list I should be using instead?)

Very excited to discover this repo. I spent a chunk of time making https://github.com/jml/rules_haskell, but had to pause 3 months ago due to workload.

When I paused, I was working on generating rules files from cabal files, in a fashion not dissimilar to gazelle (see rules_go). I’m not sure if that’s pushed anywhere public yet.

• I’m going to deprecate my repo in favour of this one
• I’d appreciate it if you take a look at my repo, see if there are any ideas worth stealing, and steal them
• If you don’t, I’ll try to find anything worth submitting
• Do you feel that something to generate BUILD files (ala gazelle) is in scope for this project? If so,

[mboes]

@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 Build rules sufficient for building inline-java #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.

[Fuuzetsu]

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.

[jml]

Lovely, thanks.

• I'll try to figure out what (if anything) jml/rules_haskell has to contribute & submit PRs.
• I've filed Generate BUILD files from Cabal descriptions #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.

[Fuuzetsu]

• There's a lot of work in Build rules sufficient for building inline-java #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 Build rules sufficient for building inline-java #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
    Generate BUILD files from Cabal descriptions #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 Generate BUILD files from Cabal descriptions #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.

[jml]

Roadmap sounds pretty good! * rules_go downloads official go binaries; I'd do likewise until we can't * I really really want to be able to compile Haskell Linux binaries from my Mac without my brain exploding. I *think* toolchains could give us this power. Next steps for me are to apply this to one of my own projects (will probably wait until #14 is merged) and then see what itches I need to scratch. I'm interested in working on #17, but expect there's more than enough work to go around there.

…

On Thu, 14 Dec 2017 at 14:17 Mateusz Kowalczyk ***@***.***> wrote: - There's a lot of work in #14 <#14> so please take that into consideration when looking at stuff to submit. I would treat that as authoritative code. @mboes <https://github.com/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 <#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 <#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 <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 <#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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#16 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHq6uroLUg7JA5qjS53hMJ-OYg5u3J_ks5tAS3kgaJpZM4RBt6n> .

[Fuuzetsu]

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.

[mboes]

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.