[Haskell-cafe] Cabal depend on local package with foreign dependencies

[Richard Lewis]

Hi Edward,

Hmm, well packageA's testA definitely *does* build without needing
include-dirs. But I've tried inserting it in case it makes a
difference for packageB; it doesn't.

But I'm now looking at the errors more carefully (and using verbose
cabal output). As pacakgeA was written some time ago, I'd forgotten
that it uses hsc. And it's actually the hsc source file which is
breaking when pacakgeB attempts to build pacakgeA.

Now, I think I've just worked out what's going on here. Typically, I'd
abstracted away one very important detail: the "other-modules" options
in my .cabal file. The module that's failing to compile is a
non-exposed module of packageA. Because it was non-exposed, I was
listing it as an "other-modules" requirement of the executable
testA. I think, therefore, that when pacakgeB tried to build testA, it
ended up trying to build it without the necessary includes.

So I've tried making this other module also exposed. (It's not ideally
what I'd like, but maybe I'll learn to live with it.) And now packageB
is able to build packageA in its sandbox.

Richard

On Tue, 27 Oct 2015 18:38:29 +0000,
Edward Z. Yang wrote:
> 
> Hello Richard,
> 
> I am not sure why package A builds in its own sandbox, but your
> copypaste suggests that executable testA does not have an include-dirs
> section which would tell it where to find foo.h.  Could that be
> the problem?
> 
> Edward
> 
> Excerpts from Richard Lewis's message of 2015-10-27 08:08:26 -0700:
> > Hi there,
> > 
> > I have two libraries that I'm working on, packageA and packageB.
> > 
> > packageA was written some time ago and depends on a foreign C library,
> > libfoo, which I also wrote and which is installed in a non-standard
> > location. packageB depends on packageA and is new and under active
> > development.
> > 
> > I have the following things, then:
> > 
> >  - libfoo is installed in ~/.local/lib, with includes in ~/.local/include/foo
> >  - packageA is in ~/src/packageA
> >  - packageB is in ~/src/packageB
> > 
> > packageA has a .cabal file which includes:
> > 
> > library
> >   build-depends: base, ...
> >   exposed-modules: A
> >   include-dirs: /home/richard/.local/include
> >   extra-lib-dirs: /home/richard/.local/lib
> > 
> > executable testA
> >   ...
> >   extra-lib-dirs: /home/richard/.local/lib
> >   extra-libraries: foo
> > 
> > I've created a cabal sandbox in packageA and I can successfully build
> > it.
> > 
> > Now, packageB makes use of packageA. It has a .cabal file which looks
> > like this:
> > 
> > library
> >   build-depends: base, packageA, ...
> >   exposed-modules: B
> > 
> > executable testB
> >   ...
> >   extra-lib-dirs: /home/richard/.local/lib
> >   extra-libraries: foo
> > 
> > Again, I've created a cabal sandbox in packageB. In order to be able
> > to use packageA (which is not installed anywhere) I believe I have to
> > do:
> > 
> > $ cabal add-source ~/src/packageA
> > 
> > Next, when I try and configure, it says:
> > 
> > cabal: At least the following dependencies are missing:
> > packageA -any
> > 
> > That's fine, I assume, because I can now just `cabal install
> > --only-dependencies` to get packageA built into packageB's
> > sandbox. But when I try and do this, I get:
> > 
> > $ cabal install --only-dependencies
> > Resolving dependencies...
> > Configuring packageA-0.1...
> > Building packageA-0.1...
> > Preprocessing library packageA-0.1...
> > In-place registering packageA-0.1...
> > Preprocessing executable 'testA' for packageA-0.1...
> > Foo.hsc:10:33: fatal error: foo/foo.h: No such file or directory
> > compilation terminated.
> > 
> > So a target of packageA which compiles fine when doing cabal build
> > directly from packageA now fails to compile when I attempt to build it
> > from packageB by installing packageB's dependencies.
> > 
> > I'm not sure how to proceed. It feels like maybe I have to tell
> > cabal--when running it from packageB--where the include files are for
> > packageA, because packageA needs to get compiled (which involves
> > linking against libfoo and using libfoo's includes). I know that
> > packageA *does* compile (because I've done that already), but it won't
> > compile inside packageB's sandbox.
> > 
> > Any suggestions?
> > 
> > Richard