RE: skipping module in .cabal
Just to make this 100% explicit: * Cabal uses ghc --make to build a bunch of .o files (including Match.o) * Cabal then links the .o files that are listed in dm.cabal (as exposed or other) to make a .a file. This list accidentally excludes Match.o * Cabal copies the .a file and the .hi files listed in dm.cabal (as exposed or other) to the install place, and registers them. Again, this list excludes Match.o As a result, a client of the package compiles all right (so long as it does not import Match) but fails at the link stage, lacking symbols in Match. This seems like a bug in Cabal, because it allows you to build and install an unusable package. Possible solutions I can think of: - Cabal does its own dependency analysis and calls GHC one module at a time - GHC gets a flag which prevents it finding any module other than those listed on the command line (although it may still do dependency analysis to figure out which order to compile them in) - The .cabal file is no longer reqd to list non-exposed modules. Instead Cabal works out what the non-exposed modules are (perhaps by calling GHC -M or something similar). Simon | -Original Message- | From: Duncan Coutts [mailto:[EMAIL PROTECTED] | Sent: 24 June 2007 04:33 | To: Serge D. Mechveliani | Cc: glasgow-haskell-bugs@haskell.org; Simon Peyton-Jones | Subject: Re: skipping module in .cabal | | On Sat, 2007-06-23 at 12:08 +0400, Serge D. Mechveliani wrote: | Dear GHC developers, | | Recently I submitted a bug report #1452 for ghc-6.6.1 | of undefined references at the stage of linking executable, | and also of ignoring un-existing module import. | | Now I discovered the following strange effect | (see the report source modules) which, probably, explains much. | | 1. (minor note) The file Match.hs-boot is not needed. | All the effects preserve after its removal. | | 2. The name `Match' must be in the list `other-modules:' | in the file | dm.cabal,which describes the package. | | But it is not in dm.cabal ! | Because I have forgotten to put it there. | | Currently Cabal uses ghc --make to build packages. It starts from all | the modules listed in the exposed-modules but ghc --make will find any | other modules that are imported, even if they are not listed in | the .cabal file in the exposed-modules or other-modules fields. | | That's the current system. The right system I think is for Cabal to do | the dependency analysis itself (it needs to do that for proper support | of pre-processors anyway). That would allow Cabal to notice when | modules | are imported but not listed in either the exposed-modules or | other-modules fields. It could issue a warning or an error. | | Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
skipping module in .cabal
Dear GHC developers, Recently I submitted a bug report #1452 for ghc-6.6.1 of undefined references at the stage of linking executable, and also of ignoring un-existing module import. Now I discovered the following strange effect (see the report source modules) which, probably, explains much. 1. (minor note) The file Match.hs-boot is not needed. All the effects preserve after its removal. 2. The name `Match' must be in the list `other-modules:' in the file dm.cabal,which describes the package. But it is not in dm.cabal ! Because I have forgotten to put it there. Further, make build still finds and compiles Match.hs. The only point where Match is needed is Reduce.hs: it imports `Match'. But why GHC finds Match.hs ? Probably, because it is in the current source directory. Then, make install succeeds. And further, the command ghc $dmCpOpt --make Main succeeds or not -- depending on whether `Match' is in dm.cabal or not! First, I think that there is my oversight here. But the GHC + Cabal system behaves strange in this example. Must not it give a plain report of what is wrong with modules or package setting ? Say, Error: `Match' is not in the package but is imported by Reduce.hs. Probably, this is the matter of Cabal. Further, if GHC still finds Match.hs and builds the package, why this undefined reference appears while linking executable ? Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: skipping module in .cabal
On Sat, 2007-06-23 at 12:08 +0400, Serge D. Mechveliani wrote: Dear GHC developers, Recently I submitted a bug report #1452 for ghc-6.6.1 of undefined references at the stage of linking executable, and also of ignoring un-existing module import. Now I discovered the following strange effect (see the report source modules) which, probably, explains much. 1. (minor note) The file Match.hs-boot is not needed. All the effects preserve after its removal. 2. The name `Match' must be in the list `other-modules:' in the file dm.cabal,which describes the package. But it is not in dm.cabal ! Because I have forgotten to put it there. Currently Cabal uses ghc --make to build packages. It starts from all the modules listed in the exposed-modules but ghc --make will find any other modules that are imported, even if they are not listed in the .cabal file in the exposed-modules or other-modules fields. That's the current system. The right system I think is for Cabal to do the dependency analysis itself (it needs to do that for proper support of pre-processors anyway). That would allow Cabal to notice when modules are imported but not listed in either the exposed-modules or other-modules fields. It could issue a warning or an error. Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
