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

Compute correct install directories for instantiated Backpack components #6317

Merged
merged 4 commits into from
Nov 3, 2019

Conversation

ezyang
Copy link
Contributor

@ezyang ezyang commented Oct 28, 2019

Previously, we would compute elabInstallDirs once when configuring a
component, and then reuse the exactly same install directories for
every instantiation of the package.  But this is wrong, since we're
installing the header/object files for each instantiation to a different
directory.  We refactor install directory computation into a helper
function and then call it again at instantiation time to refresh
the install directories.

For some reason, this bug ONLY manifests for packages installed from
Hackage; it seems install dirs are not respected for inplace packages.

Fixes #6005

Previously, we would compute elabInstallDirs once when configuring a
component, and then reuse the exactly same install directories for
every instantiation of the package.  But this is wrong, since we're
installing the header/object files for each instantiation to a different
directory.  We refactor install directory computation into a helper
function and then call it again at instantiation time to refresh
the install directories.

For some reason, this bug ONLY manifests for packages installed from
Hackage; it seems install dirs are not respected for inplace packages.

Fixes haskell#6005

Signed-off-by: Edward Z. Yang <[email protected]>
@ezyang ezyang requested review from dcoutts and andrewthad October 28, 2019 00:50
@ezyang
Copy link
Contributor Author

ezyang commented Oct 28, 2019

cc @vmchale

Signed-off-by: Edward Z. Yang <[email protected]>
@andrewthad
Copy link
Contributor

Thanks for working on a fix for this! I've tried it out in a fresh container by cloning the branch, installing ghc-8.6.5, and running the bootstrap script to install cabal, and I get a different error than I used to. Here's the build log:

Configuring library 'sockets-datagram-receive' for sockets-0.5.0.0..
Warning: The package has an extraneous version range for a dependency on an
internal library: sockets -any && ==0.5.0.0 && ==0.5.0.0 && ==0.5.0.0, sockets
-any && ==0.5.0.0 && ==0.5.0.0 && ==0.5.0.0, sockets -any && ==0.5.0.0 &&
==0.5.0.0 && ==0.5.0.0. This version range includes the current package but
isn't needed as the current package's library will always be used.
Preprocessing library 'sockets-datagram-receive' for sockets-0.5.0.0..
Building library 'sockets-datagram-receive' instantiated with
  Datagram.Receive = <Datagram.Receive>
  Socket.Buffer = <Socket.Buffer>
  Socket.Interrupt = <Socket.Interrupt>
for sockets-0.5.0.0..
[1 of 4] Compiling Socket.Buffer[sig] ( dist/build/sockets-datagram-receive/autogen/Socket/Buffer.hsig, nothing )
[2 of 4] Compiling Datagram.Receive[sig] ( src-datagram-receive/Datagram/Receive.hsig, nothing )

src-datagram-receive/Datagram/Receive.hsig:7:1: warning: [-Wunused-imports]
    The import of ‘Data.Primitive.PrimArray.Offset’ is redundant
      except perhaps to import instances from ‘Data.Primitive.PrimArray.Offset’
    To import instances alone, use: import Data.Primitive.PrimArray.Offset()
  |
7 | import Data.Primitive.PrimArray.Offset (MutablePrimArrayOffset)
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

src-datagram-receive/Datagram/Receive.hsig:9:1: warning: [-Wunused-imports]
    The import of ‘CInt’ from module ‘Foreign.C.Types’ is redundant
  |
9 | import Foreign.C.Types (CSize,CInt)
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

src-datagram-receive/Datagram/Receive.hsig:10:1: warning: [-Wunused-imports]
    The import of ‘GHC.Exts’ is redundant
      except perhaps to import instances from ‘GHC.Exts’
    To import instances alone, use: import GHC.Exts()
   |
10 | import GHC.Exts (RealWorld)
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^

src-datagram-receive/Datagram/Receive.hsig:12:1: warning: [-Wunused-imports]
    The import of ‘Posix.Socket’ is redundant
      except perhaps to import instances from ‘Posix.Socket’
    To import instances alone, use: import Posix.Socket()
   |
12 | import Posix.Socket (SocketAddress,SocketAddressInternet)
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[3 of 4] Compiling Socket.Interrupt[sig] ( dist/build/sockets-datagram-receive/autogen/Socket/Interrupt.hsig, nothing )
[4 of 4] Compiling Datagram.Receive.Indefinite ( src-datagram-receive/Datagram/Receive/Indefinite.hs, nothing )
Installing internal library sockets-datagram-receive in /root/.cabal/store/ghc-8.6.5/incoming/new-2047/root/.cabal/store/ghc-8.6.5/sockets-0.5.0.0-495643d155551acae808a8d25d861888f010b4b962f2d1e8b05baa22ccb89342/lib
cabal: '/usr/local/bin/ghc' exited with an error:
Failed to load interface for ‘Data.Attoparsec.ByteString.Char8’
no unit id matching
‘attoparsec-0.13.2.3-1da906b1053cab59d5c799d20d77f038c525df8cf0400fb81ec6ece5a908f5c3’
was found

It's entirely possible that I messed up installing cabal. I've not installed cabal from github before, and I may have goofed.

@ezyang
Copy link
Contributor Author

ezyang commented Oct 30, 2019

@andrewthad oh, that's an interesting error. Does it happen if your Backpack packages are all inplace? (Is this the repro instructions from the original issue?)

@andrewthad
Copy link
Contributor

Sorry, I didn't follow my own instructions. With:

cabal install -w /opt/ghc/bin/ghc-8.8.1 --ghc-options='-dppr-debug' --lib sockets-0.5.0.0

It succeeds. Hooray!

@ezyang
Copy link
Contributor Author

ezyang commented Oct 31, 2019

I need to version guard the test but it looks like everything else is good.

@hvr
Copy link
Member

hvr commented Nov 2, 2019

I need to version guard the test but it looks like everything else is good.

@ezyang fyi, I just pushed ff7f5df to your PR

@ezyang
Copy link
Contributor Author

ezyang commented Nov 3, 2019

Thanks @hvr!

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 this pull request may close these issues.

Problems using cabal-install with backpack
3 participants