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