-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider exposing all files in a filegroup #9
Comments
Fuuzetsu
added a commit
to tweag/inline-java
that referenced
this issue
Dec 26, 2017
This is a collection of build files that work with the given WORKSPACE file. This should allow the user to run `bazel run //:spec` which will build inline-java and run the spec tests. * I'm using GHC 8.0.2 as I was unable to quickly find working 8.2.2 set. * We're taking open JDK header files from bazel but the libraries from nix. Neither exposes both: tweag/rules_nixpkgs#9 * We're repeating ourselves a lot w.r.t. prebuilt dependencies. We need to have all the packages available to GHC at WORKSPACE level then we also need to know them at BUILD level. We can't just define them in WORKSPACE and refer to them from BUILD as WORKSPACE only works in current project: if user wants to use inline-java from another project, the WORKSPACE file here is irrelevant: indeed they'll have to define all these things in their own WORKSPACE. * `rules_nixpkgs` commit points at a temporary branch which includes changes from two outstanding PRs, both of which are needed to build inline-java * `spec` target would be better as some `haskell_test` once that exists * We're giving too many shared openjdk libs during build: we only need libjvm.so and maybe libjni.so but we don't have granular control over the filegroup so we end up using every shared lib in openjdk package which is not ideal.
What are filter filegroups? |
I mean can you take a filegroup as a user and filter it, only passing some subset of files to rules &c. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently we only expose
.so
files fromlib
and things frombin
: this is quite restrictive: we can't use header files or use binaries that don't live directly inbin
&c.Is there any good reason to not have an
out
file group that user can reach for?Related question: can use filter filegroups? That'd be very useful.
The text was updated successfully, but these errors were encountered: