Skip to content
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

Closed
Fuuzetsu opened this issue Dec 26, 2017 · 2 comments · Fixed by #35
Closed

Consider exposing all files in a filegroup #9

Fuuzetsu opened this issue Dec 26, 2017 · 2 comments · Fixed by #35

Comments

@Fuuzetsu
Copy link
Collaborator

Currently we only expose .so files from lib and things from bin: this is quite restrictive: we can't use header files or use binaries that don't live directly in bin &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.

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.
@mboes
Copy link
Member

mboes commented Dec 26, 2017

What are filter filegroups?

@Fuuzetsu
Copy link
Collaborator Author

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
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants