November 2010 - cabal-devel

[Hackage] #671: better error message for broken build tools
by Hackage 05 Jan '12

05 Jan '12

#671: better error message for broken build tools ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.4 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Consider: {{{ Configuring haskell-src-exts-1.9.0... setup: happy version >=1.17 is required but the version of /usr/local/bin/happy could not be determined. }}} The actual problem is: {{{ /usr/local/bin/happy: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory }}} We could produce a better error message in this situation. If we get a non-0 exit code when we check the `--version` then we can probably safely report that the program is probably broken. Of course if we get some result text back and we cannot extract and parse the version number then that's different. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/671> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #663: Setup.hs doesn't look into ~/.cabal/bin for build tools.
by Hackage 05 Jan '12

05 Jan '12

#663: Setup.hs doesn't look into ~/.cabal/bin for build tools. ----------------------------------+----------------------------------------- Reporter: Axel Simon | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- Cabal currently only checks the current PATH for buildtools. If the user installs and new pre-processor with the default --user installation, these tools wind up in ~/.cabal/bin. However, cabal doesn't find these unless ~/.cabal/bin has been added to the PATH. This is irritating since it is then not possible to make a library depend on a cabal package that contains it's build tools: Even if cabal-install installs the build tools first, building the library still fails since the tools cannot be found. The solution is very simple: Add ~/.cabal/bin to the search path when looking for build tools! -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/663> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #701: Help packages to avoid linker symbol clashes
by Hackage 05 Jan '12

05 Jan '12

#701: Help packages to avoid linker symbol clashes ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Currently it is all too easy to end up with silently clashing linker symbols. The prime example is C code linked into a Haskell package. Multiple versions of the same package will define the same linker symbols. The system linker is happy to just pick the first occurrence of a symbol (though the ghci linker is stricter). This can cause havoc if the behaviour of the C code changes from one version of the package to another (see for example the problem with mmap and darcs, ticket #700). There are a number of things we could do to improve the situation. * We could make it easier to make versioned C symbols in the C code used in a Haskell package by providing cpp macros. * We could explicitly check for unversioned C symbols in Haskell libs * We could try linking Haskell libs in such a way that the C symbols are not visible and thus cannot clash, but it would also mean they are not exported for other libs to use. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/701> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #766: hackage build logs gone missing?
by Hackage 05 Jan '12

05 Jan '12

#766: hackage build logs gone missing? --------------------------------+------------------------------------------- Reporter: claus | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- It seems that build logs are no longer linked from package pages (used to be linked from the `built on` entries, iirc), such as: http://hackage.haskell.org/package/haddock Also, the `latest/` directory has `doc/`, but not `logs/`, while the archived versioned directory has both: http://hackage.haskell.org/packages/archive/haddock/latest/ http://hackage.haskell.org/packages/archive/haddock/2.8.1/ And, since I've more than once confused myself with that directory structure (`package` singular, but `packages/archive` plural? why the different prefix, where a version number postfix should be enough? why both `http://hackage.haskell.org/package/haddock-2.8.0` and `http://hackage.haskell.org/packages/archive/haddock/2.8.0/`?), could that be simplified (or, at least, a link be provided from the `package`-entry to the shadow-hierarchy `packages/archive`)? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/766> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[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