cabal should fail if compilation depends on a file not existing in the cabal file #939

Closed
bos opened this Issue May 24, 2012 · 8 comments

Comments

Projects
None yet
8 participants
Contributor

bos commented May 24, 2012

(Imported from Trac #949, reported by LeventErkok on 2012-05-11)

Cabal doesn't complain if the build depends on a Haskell module that exists in the filesystem properly, but is not mentioned in the cabal file itself as part of "exposed-modules" or "other-modules". The build succeeds because ghc can find the relevant file just fine.

I've got bitten by this several times, especially after pushing a package to hackage, only to get it fail to build on the server because I've failed to put the name of a file in the appropriate section of the cabal file, thus it didn't make it to the .tar.gz bundle that got uploaded to the server.

I realize this might be hard to ensure, as it would require a deeper look into the dependencies between modules, but I trust the GHC API should have all the information necessary for cabal to complain appropriately.

On my 64bit machine I got the following strange linker error when I forgot to register a module in the Cabal file:

/usr/bin/ld: dist/build/.../Module.dyn_o: relocation R_X86_64_PC32 against
undefined symbol `..._xyz1_closure' can not be used when making a shared
object; recompile with -fPIC

I second this as a bug! We ran into this colah/ImplicitCAD#61 it is quite a nasty little bugger when all you get is a link error with no info. If this can't be fixed in cabal, perhaps GHC could at least give us a hint as to the source of the link error?

See issue: #22

Collaborator

dagit commented Apr 12, 2013

I just helped someone in #haskell with this problem. For them it was appearing because their test-suite section depended on a package that forgot to mention some modules in the other-modules list.

I found the solution by search my irc logs for the last time I helped someone with this. What I'm trying to say is, this is a pretty common problem. Is there any way to increase the priority of this bug? Perhaps adding it to the next milestone.

Thanks!

Member

23Skidoo commented Apr 12, 2013

This requires either parsing the output of ghc -M or a GHC option to blacklist all modules not included in exposed-modules and other-modules.

Hi, I just ran into this problem again. I thought I'd bump this issue because it hasn't received any attention in a while and I believe it's important enough to fix. Also I believe this should be labeled as bug rather than enhancement because cabal doesn't produce a valid library if someone forgets to mention a module in their cabal file.

schell commented Dec 9, 2014

I just ran into this myself with schell/steeloverseer#6. It looks like I deleted the "other-modules" line of my cabal file at some point trying to clean it up. /facepalm

ttuegel added the duplicate label Feb 28, 2015

Member

ttuegel commented Feb 28, 2015

Duplicate of #1746.

ttuegel closed this Feb 28, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment