December 2011 - cabal-devel

[Hackage] #787: --test-option should support template argument
by Hackage 05 Jan '12

05 Jan '12

#787: --test-option should support template argument ----------------------------------+----------------------------------------- Reporter: tibbe | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- The test-framework package can optionally output JUnit XML, an XML flavor understood by many continuous build systems, if you pass it the `--jxml` flag. Using that flag, one can get `cabal test` to output JUnit XML: {{{ cabal configure --enable-tests cabal build cabal test --test-option=--jxml=dist/test/junit.xml }}} However, the `--test-option` flag doesn't allow the user to pass different flags to different test executables so each test executable will override the output of the previous. If the `--test-option` flag took a name template argument, supporting a `$test-suite` placeholder, you could generate one JUnit XML file per test suite: {{{ cabal configure --enable-tests cabal build cabal test --test-option=--jxml=dist/test/$test-suite.xml }}} The detailed test interface might support this in some nicer way, but this is a cheap way to have Cabal cooperate better with other test runners. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/787> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #843: 'cabal test' crashes on Windows
by Hackage 05 Jan '12

05 Jan '12

#843: 'cabal test' crashes on Windows ----------------------------+----------------------------------------------- Reporter: ttuegel | Owner: ttuegel Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.10.1.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Windows | ----------------------------+----------------------------------------------- Cabal crashes with the following error on Windows Vista and 7 (I have not tried XP): {{{ Running 1 test suites... Test suite tests: RUNNING... Test suite tests: PASS Test suite logged to: dist\test\foo-0.1-tests.log cabal: permission denied }}} The "permission denied" error appears to be from an attempt to delete a temporary file while it is still open. This does not appear to cause problems on Unix, but Windows won't allow it. I believe it is due to the fact that the temporary log file is read lazily, so it doesn't get closed before the file is deleted. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/843> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #839: hackage: produce haddock documentation for executable only projects as well
by Hackage 05 Jan '12

05 Jan '12

#839: hackage: produce haddock documentation for executable only projects as well --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- Hackage currently only contains haddock documentation for "libraries". However, it'd be really cool to be able to see the source code of "executable" only projects as well. If the project is not haddock'ized, then a simple hscolor'ed html source base would be fine as well (like in GitHub). One of the more common use cases of Hackage is to look at other people's code, even for projects that you wouldn't download. This can go along way in making that much more pleasurable. Alternatively, the user can specify a cabal flag to indicate if he wants browsable source code to be produced in case of executable only projects. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/839> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #779: Create tarball of all Hoogle input files
by Hackage 05 Jan '12

05 Jan '12

#779: Create tarball of all Hoogle input files --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: HackageDB Component: hackageDB website | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- For many packages on Hackage there is a corresponding Hoogle input file, for example: http://hackage.haskell.org/packages/archive/cmdargs/0.6.5/doc/html/cmdargs.… To generate Hoogle databases for every package on Hackage I have a script that downloads the documentation for every package, then puts it in a tarball and uploads it back to http://haskell.org/hoogle/hackage- haddock.tar.gz There are three disadvantages to the current process. It's quite a lot of connections to Hackage to download every single file, it takes quite a lot of time to download them individually (about 50 minutes using wget serially), and the tarball on Hoogle is often (always?) out of date. Would it be possible for Hackage to supply a tarball of all the Hoogle input files? -- Neil Mitchell (Hoogle author) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/779> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 8

[Hackage] #792: sdist doesn't not include source files from test-suite stanzas
by Hackage 05 Jan '12

05 Jan '12

#792: sdist doesn't not include source files from test-suite stanzas ----------------------------+----------------------------------------------- Reporter: tibbe | Owner: ttuegel Type: defect | Status: new Priority: normal | Milestone: Cabal-1.10 Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- `cabal sdist` doesn't include the source files from test-suite stanzas when generating the tarball. This leads to Hackage's QA checks rejecting the package. Steps to reproduce: 1. Create a Cabal package with a test-suite stanza (and set `hs-source- dirs` to e.g. `tests`). 2. Run `cabal sdist` 3. Unpack the tarball and look at the content. Thomas, could you please take a look? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/792> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 8

[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