-
Notifications
You must be signed in to change notification settings - Fork 10
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
.HaskellCompile.pb: openBinaryFile: does not exist #10
Comments
Ah, yeah, this is an unfortunate behavior. What I'd really like is for the One possibility I've thought about would be to record more information about the graph of transitive dependencies in HaskellCompileInfo, and do the For now, though, the approach you suggested sounds like a reasonable workaround. Would you like to send a patch? By they way, even if we resolve this issue with genrules, you may have a problem loading everything into gghci at once; GHCi gets confused if you try to give it two source files that both have a "Main" module. In the case you mentioned, it might be fine since generate-stable-packages has a custom main_function. |
That sounds interesting. Could you expand a bit on what you have in mind? I'm not sure I understand how this would work.
I've opened #11 implementing this filter.
That's a good point. In this particular case we do indeed get away with it. Only #11 fixes the
Fails with "could not load module" errors due to missing
I'm not sure what is causing this. In case of |
@aherrmann |
The idea is not particularly well-formed yet, to be honest. Here's one possibility: For each Haskell rule, add a
Then, replace
Some things I'm not sure about;
|
I dug a bit deeper. The issue is not due to the filter that I added in #12. The filter for The compiled dependencies are determined by the query defined in
Running this query indeed doesn't include It turns out that |
Thanks for outlining the |
hrepl
attempts to build thehaskell_compile_info
output group of non-Haskell targets even if they are not explicitly listed on the command-line.This issue can be reproduced on the
daml
repository as follows:Both targets that are specified on the command line are
haskell_binary
targets. The failing target//compiler/damlc/stable-packages:gen-stable-packages
is agenrule
target.Setting the
--show-commands
flag shows that that target first appears after the firstallpaths
query:Indeed,
//compiler/damlc:damlc-bootstrap
has adata
dependency on//compiler/damlc/stable-packages
which is afilegroup
capturing the outputs of thegenrule
//compiler/damlc/stable-packages:gen-stable-packages
which in turn has atools
dependency on//compiler/damlc/stable-packages:generate-stable-package
.One could argue that it doesn't make sense to try and load both those binaries into one GHCi session. Unfortunately, that doesn't prevent this issue as both
haskell_binary
targets share common library dependencies. E.g. the following will trigger the same issuewhere
//compiler/damlc/daml-lf-conversion
is ahaskell_library
target.Unfortunately, I'm not aware of a
cquery
command to filter out targets that don't provide a certain output group. However, one possible way to avoid this issue would be to filter for Haskell rules before attempting to build the output groups. E.g.kind("haskell_binary|haskell_library|haskell_test", ...)
forcompile_info
andkind("haskell_library|haskell_cabal_library", ...)
forlibrary_info
. This would potentially also allow users to pass wildcards tohrepl
, e.g.hrepl revision 33f879e
daml revision 761efbe0856941ab398925846dee0d4bbf0b1811
The text was updated successfully, but these errors were encountered: