- cabal-devel - Haskell.org

Re: [Hackage] #352: cabal-install has problems with some HTTP proxies
by Hackage 05 Jan '12

05 Jan '12

#352: cabal-install has problems with some HTTP proxies --------------------------------+------------------------------------------- Reporter: BMeph | Type: defect Status: closed | Priority: normal Milestone: cabal-install-0.6 | Component: cabal-install tool Version: HEAD | Severity: normal Resolution: fixed | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: Windows | --------------------------------+------------------------------------------- Comment(by elga): * [http://www.releve-identite-operateur.fr/rio-bouygues.html rio bouygues] -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/352#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #359: Warn if package index is older than X days
by Hackage 05 Jan '12

05 Jan '12

#359: Warn if package index is older than X days ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: closed Priority: normal | Milestone: cabal-install-0.6 Component: cabal-install tool | Version: HEAD Severity: normal | Resolution: fixed Keywords: | Difficulty: very easy (<1 hour) Ghcversion: 6.8.2 | Platform: ---------------------------------+------------------------------------------ Comment(by elga): * [http://www.releve-identite-operateur.fr/numbero-de-virgin-mobile.html virgin mobile] -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/359#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #865: Can't use command line options containing spaces
by Hackage 05 Jan '12

05 Jan '12

#865: Can't use command line options containing spaces ----------------------------+----------------------------------------------- Reporter: bos | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.10.1.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I found myself wanting the other day to pass some specific RTS options to GHC on the command line, with those options varying depending on the version of GHC: {{{ghc-options: --with-rtsopts="-N -qg"}}} However, Cabal doesn't tokenize command line options, and GHC doesn't treat multiple {{{--with-rtsopts}}} arguments as building up a single string, so I found myself stuck. (I know about the "specify the options in a {{{.c}}} file, and that's what I did, but it's less elegant.) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/865> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[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