February 2011 - cabal-devel

[Hackage] #735: cabal haddock --executables --hyperlink-source does not call HsColour
by Hackage 05 Jan '12

05 Jan '12

#735: cabal haddock --executables --hyperlink-source does not call HsColour ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ I am using "cabal haddock --executables --hyperlink-source" and this generates the API docs for all modules, and all have source links, but the actual html-ized source is only generated for the main module, and missing for all others. Cf. discussion at http://article.gmane.org/gmane.comp.lang.haskell.cafe/78987 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/735> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #742: build-depends in Executable sections are unexpectedly global
by Hackage 05 Jan '12

05 Jan '12

#742: build-depends in Executable sections are unexpectedly global ----------------------------+----------------------------------------------- Reporter: benmachine | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- When I have two executable sections, it seems that the build-depends of one are used in the other. For example, the following: state.cabal {{{ Cabal-Version: >= 1.2 Name: state Version: 0.1 Build-type: Simple Executable state-tf Main-is: Main.hs Build-depends: base, transformers, monads-tf Executable state-mtl Main-is: Main.hs Build-depends: base, mtl }}} Main.hs {{{ module Main where import Control.Monad.State main = print $ runState (put ()) undefined }}} fails to compile: {{{ Preprocessing executables for state-0.1... Building state-0.1... Main.hs:3:7: Ambiguous module name `Control.Monad.State': it was found in multiple packages: monads-tf-0.1.0.0 mtl-1.1.1.0 }}} If this is intended (which I doubt) it's at least confusing. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/742> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #746: Cabal should complain if you give an upperbound on Cabal-Version
by Hackage 05 Jan '12

05 Jan '12

#746: Cabal should complain if you give an upperbound on Cabal-Version ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Some packages (e.g. `NaturalSort-0.2.1`) give an upper-bound on `Cabal- Version`. This doesn't make sense for this field, so Cabal should complain about it (or perhaps even reject it). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/746> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #757: Building shared libraries to simplify C++ wrappers
by Hackage 05 Jan '12

05 Jan '12

#757: Building shared libraries to simplify C++ wrappers ------------------------------+--------------------------------------------- Reporter: jodonoghue | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: minor | Keywords: C++, library Difficulty: project(> week) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- While Haskell cannot directly link with C++ code via the FFI, it is straightforward and pretty common practice to write wrapper functions which are callable using C conventions. These can be used from the FFI. As an example, consider the method functions setFoo and getFoo in the class Bar. Ignoring const correctness and general good design, this might look something like: {{{ class Bar { private: String& val; public: Bar() { val = ""; } String& getFoo() { return val; } void setFoo(const String& v) { val = v; } } }}} C language wrappers would be something like: {{{ void* "C" Bar_constructor() { return (void*) new Bar; } char* "C" Bar_getFoo(void* ths) { return (char *) ((Bar*) ths)->getFoo(); } void "C" Bar_setFoo(void* ths, char* val) { ((Bar*) ths)->setFoo(String(val)); } }}} Cabal is quite capable of compiling this today, but a problem can arise when the code is linked. The issue is that most C++ code needs to be linked with the C++ standard library, libstdc++ (in the example above, it is needed for the String type). On Windows, the MinGW compiler provided in Haskell Platform provides only a static version of libstdc++. When compiling with GHC, this is not an issue, since static linking to libstdc++ works just fine. However, when loading the library into GHCi, loading fails because no shared version of libstdc++ exists, and fix-up fails when attempting to load libstdc++. The proposed solution is to extend Cabal so that C or C++ code listed in the c-sources stanza can (optionally) be built as a shared library. The shared library can safely be linked with a static libstdc++, which removes the need to export this dependency to Haskell (GHC/GHCi need only link to the shared lib). Concretely, this could be implemented as follows: Add a new section {{{ForeignLibrary}}} This would need to contain the following stanzas: '''foreign-lib-name: <name>''' This is the basename of the library (i.e. without the 'lib' prefix on Unix, and without any extension (.a, .so, .dll) - as this basename is cross-platform compatible. '''foreign-lib-type: shared | static''' Indicate whether the library should be compiled as a shared library (.dll, .so, .dylib etc) or as a static library (.a, .lib). '''foreign-lib-extralibs: <list of libs>''' A list of libraries with which the foreign library must be linked. In the case where the library is being built as '''shared''', these will not be added to the list of libraries in the module '''extra-libraries''' stanza. Where the foreign library is built as '''static''' these libraries need to be added to '''extra-libraries''' '''foreign-lib-libdirs: <list of directory paths>''' Each path gets added to a -L<path> when compiling C/C++ code. '''foreign-lib-includes: <list of directory paths>''' Each path gets added to a -I<path> when compiling C/C++ code. '''foreign-lib-generate-def: True | False''' For Windows only, if the library is being built as a '''shared''' library, generate the corresponding .def file detailing the exported functions. '''cc-options''', '''ld-options''' and '''frameworks''' should function in the same way as they do in Cabal today. I believe that this set of changes would be sufficient to allow wrapping of many C++ libraries without the need for significant customization of the Cabal Simple profile. I believe that it might also simplify porting of foreign libraries which were originally designed for Unix systems to run on Windows, since there would be a standard way to build C/C++ code for inclusion with Haskell modules. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/757> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #734: support multiple .cabal files
by Hackage 05 Jan '12

05 Jan '12

#734: support multiple .cabal files ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ if there are several *.cabal files in the working directory, then "cabal configure" complains, and does nothing. That's OK, but it should then have an option for picking one of these files (cf. "make -f FILE"). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/734> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #736: Win32 missing
by Hackage 05 Jan '12

05 Jan '12

#736: Win32 missing --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: HackageDB Component: hackageDB website | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- I have uploaded a package to Hackage but it had a build failure: cabal-setup: At least the following dependencies are missing: Win32 -any If Win32 library is missing, all packages with Win32 as dependency will have a build failure. I guess the Win32 build failure is the source of the problem. Although, its documentation is well built (manually, I guess). In my computer, the package installs correctly, because Win32 comes with the Haskell Platform. But, in my opinion, online documentation should work fine. Thanks in advance. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/736> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #785: check fails "No (or multiple) ghc rts package is registered"
by Hackage 05 Jan '12

05 Jan '12

#785: check fails "No (or multiple) ghc rts package is registered" ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- For packages that do not depend indirectly on the rts package (ie that have no dependencies specified at all), then the check in the hsc2hs package for the rts package fails. {{{ hackRtsPackage index = case PackageIndex.lookupPackageName index (PackageName "rts") of [(_, [rts])] -> PackageIndex.insert rts { Installed.ldOptions = [] } index _ -> error "No (or multiple) ghc rts package is registered!!" }}} The reason is that we only store the transative deps of the package in the saved config, so the rts package is not found. This is of course not a helpful error message. We should remove this check from this place and add something else elsewhere with a more helpful error message. We could do a sanity check during configure or build (but note that we don't do it anymore when configuring ghc itself due to the odd things ghc does during its own build process). We should probably have a build warning about missing the base package. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/785> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #756: weird ghc dependency on array
by Hackage 05 Jan '12

05 Jan '12

#756: weird ghc dependency on array ---------------------------------+------------------------------------------ Reporter: graphov | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: cabal-install dependency Difficulty: unknown | Ghcversion: 6.12.1 Platform: Linux | ---------------------------------+------------------------------------------ I've upgrade Cabal to current version using cabal-install and got this weird dependency error: druid@lambda-server:~$ cabal install on-a-horse Resolving dependencies... cabal: dependencies conflict: ghc-6.12.1 requires array ==0.3.0.1 however array-0.3.0.1 was excluded because ghc-6.12.1 requires array ==0.3.0.0 Seems like ghc-6.12.1 depends on both arrays simultaneously. Ubuntu 10.10 amd64 ghc 6.12.1, shipped with Ubuntu All other packages are built from hackage, not from Ubuntu packages -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/756> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #798: install gives "removeLink: does not exist" for a dependency that exists
by Hackage 05 Jan '12

05 Jan '12

#798: install gives "removeLink: does not exist" for a dependency that exists ----------------------------+----------------------------------------------- Reporter: tsueako | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.12.3 Platform: Linux | ----------------------------+----------------------------------------------- In installing regex-pcre in an installation with regex-base already installed, I get: Registering regex-base-0.93.2... /usr/bin/ghc-pkg update - --global --no-user-package-conf cabal: ghc-pkg: /usr/lib/ghc-6.12.3/package.conf.d/regex- base-0.93.2-93d41c404776e7153a3c56abb15299c9.conf: removeLink: does not exist (No such file or directory) and regex-pcre does not install. However, prior to running cabal 'ghc-pkg list' had shown that regex-base was already installed. I suspect this is a problem due to the way haskell is installed on Fedora. Basically, you: 1. install a haskell-platform rpm, which leads to a bunch of ghc rpms being installed. 2. you supplement these rpms with any other Fedora haskell package rpms you may need. At this point everything works. 3. when you cabal install other packages from hackagedb, 1 of 3 things usually happens: a. install is successful. b. install fails, but can be done by using an older version of the package. c. install fails as above. I have already submitted a bug report to Fedora, and they thought it might be useful to kick it up. BTW, I have also noticed that the global package.conf.d directory has a mixed format (entries with and w/o a hash) as in: random-1.0.0.2-f4208c3677aeaaaf41e4d36309c0b4ff.conf ranges-0.2.3-2cf5a2473b624130e73c098781871f09.conf regex-base-0.93.2.conf -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/798> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #751: Cabal confused about DeriveFunctor
by Hackage 05 Jan '12

05 Jan '12

#751: Cabal confused about DeriveFunctor ---------------------------------+------------------------------------------ Reporter: osaunders | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.12.3 Platform: Mac OS | ---------------------------------+------------------------------------------ Full details here: http://stackoverflow.com/questions/4001749/is- derivefunctor-a-well-recognized-extension-cabal-seems-confused/4001965 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/751> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5