Comments (7)
@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
theninline-java
projects compiling (which they now do as of weekend in #14). My next goal is to getsparkle
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 oncesparkle
works, we will want to step out into more general implementations. mboes suggested trying to buildAgda
. 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.
- do whatever it takes to get
- 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.
Related Issues (20)
- rts dependency in cc_library no longer works (can't find HsFFI.h) HOT 5
- Refactor Bazel configuration to reduce/eliminate platform-specific flags HOT 3
- `ghc_wrapper` is killed on MacOS arm64 running tests under `rules_haskell_tests` HOT 6
- Prepare release 0.19
- Update BCR presubmit to use `rules_haskell` instead of running the tests in `rules_haskell`
- Upgrade to new rules_nixpkgs release
- Buildifier support on NixOS with bzlmod HOT 1
- Haddock 2.30 faillure in profiling mode
- proto-len protoc plugin failures on windows with ghc 9.6.2 and 9.8.1
- Docker example should work on Darwin
- Dependency Dashboard
- Bazel 7.1.1 and nixpkgs GHC 9.8.2 produce dynamically linked haskell_cabal_binary's
- Avoid creating empty libraries
- [Bazel CI] Unrecognized option incompatible_struct_has_no_methods in bazel command HOT 3
- build on Bazel CI broken HOT 2
- [Bazel CI] library tests are failing with Bazel@HEAD HOT 8
- C-only cabal libraries fail to build with haddock = True HOT 3
- Project created through `start` script doesn't build in nix shell HOT 4
- Support both bzlmod and nix in `start` script
- Using `nix_file_deps` in `rules_haskell_toolchains` extension causes error
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rules_haskell.