December 2010 - cabal-devel

[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] #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] #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

[Hackage] #750: Distribution\Client\Dependency\TopDown.hs:171:37-73: Non-exhaustive patterns in lambda
by Hackage 05 Jan '12

05 Jan '12

#750: Distribution\Client\Dependency\TopDown.hs:171:37-73: Non-exhaustive patterns in lambda ----------------------------+----------------------------------------------- Reporter: guest | 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: Windows | ----------------------------+----------------------------------------------- C:\Users\suszynsk>cabal install syb Resolving dependencies... cabal: dependencies conflict: base-3.0.3.2 requires syb ==0.1.0.2 however syb-0.1.0.2 was excluded because syb-0.2.2 was selected instead C:\Users\suszynsk>cabal install base Resolving dependencies... cabal: Distribution\Client\Dependency\TopDown.hs:171:37-73: Non-exhaustive patterns in lambda -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/750> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #741: cabal-install: wrong use of mktemp in bash completion script
by Hackage 05 Jan '12

05 Jan '12

#741: cabal-install: wrong use of mktemp in bash completion script ---------------------------------+------------------------------------------ Reporter: nomeata | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ---------------------------------+------------------------------------------ The following bug was reported by Jan Braun against the Debian bugtracker at http://bugs.debian.org/597769 Hi, the bash completion script 1) does not check the return value of mktemp and 2) fails in the presence of "set -o noclobber" attached is a patch to fix both. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/741> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #730: patch: add a separator before the pid suffix to the tmpdir template
by Hackage 05 Jan '12

05 Jan '12

#730: patch: add a separator before the pid suffix to the tmpdir template ----------------------------------+----------------------------------------- Reporter: juhp | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- Currently Cabal appends the pid directly to the package name-version which makes it hard to read the actual package version number. The attached patch inserts a '-' between name-version and pid. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/730> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1